Re: model problem: access count
Re: model problem: access count
- Subject: Re: model problem: access count
- From: Chuck Hill <email@hidden>
- Date: Tue, 5 Sep 2006 11:02:16 -0700
Hi,
On Sep 2, 2006, at 5:25 PM, YL wrote:
I have some content management related entities:
EContent, EPublication, WLink, WCategory
EContent stores various contents, can be dynamic wo pages or static
contents, even web references.
EPublication adds business settings to EContents: WCategory defines
the site navigation structure
(a forest of 'web folders') and WLink present the associations
between EPublications and WCategories,
it also defines the corresponding web links.
EContent can have quite complex sub structures, that's not what my
model problem about. My model
problem is about the accessCount attribute in EPublication.
I would not do that. I would store the access count someplace else
and make it one object/row per access rather than updating a single
number. That way updates are only an insert and you don't have to
worry about update related issues. A qualified count(*) will produce
the summary numbers when needed.
(1) how to count access. currently I used session access:
accessCount will increase by 1 and only 1
if within a session the publication been requested. any use
cases that need more smart counting?
That seems more like a business question for you, as to what you want
counted as an additional access.
(2) the updating of accessCount can be a headache: there may be
multiple sessions request the publication
at the sametime. Also, how to schedule the access count
updating?, there may be some eo changes
within a session editingContext which are not intend to commit
or not ready to commit yet, while the
accessCount needs to be increased no matter what happened.
Use different editing contexts for editing the EO and for inserting
the new access count object. If performance of access counting is a
concern, use raw JDBC to do the inserts.
(3) There may be a need to show the current access count besides
the web link referencing the publication
so it better to update itself as soon as possible
See count(*) above. You are going to want to cache this, probably at
the application level, and only update it every few minutes. You
don't want to overload your database just to show some numbers that
most people won't pay much attention to.
(4) There may be a business rule that after accessCount reaches a
value, the access policy will change.
Again, not hard to do, but watch how often you are counting the rows.
Chuck
So what''s a reliable way to deal with counting problems?
That is the most reliable / lowest pain way to do it. If you really
need frequent access to up to date access counts, there is an "offset
update qualifier" (not sure what it was called, Jon Rentsch's maybe?)
that did an update foo set bar = bar + 1; Which could also be used.
Maybe someone else will recall what it is called / where it is (any
guesses for Project Wonder?). You would want to exclude the
accessCount as a locking attribute if you do this.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden