On Thu, Feb 15, 2001 at 11:26:04AM -0800, John McNally wrote:
> Mostly the rationale is that I was unsure of all the consequences of changing the
>simple
> attribute while other object relationships may exist due to the foreign key. For
>example
> object A object may be
> in a collection of object B due to the foreign key attribute A.b. I did not want to
>add
> such integrity checks to A.setB_ID or more correctly did not have the
>time/intelligence to
> make sure the relationships remained valid.
I see. Actually in the case that prompted me to suggest this, I wasn't
using the foreign-table side collection accessors, so I had forgotten
that there could potentially be a cached collection that would be
invalidated. But like you say, setting the foreign key ID isn't the only
way to invalidate the collection anyway.
Its an interesting problem though, I may mull on it a little - although
I'm not sure there's an easy way around it. Like you say it may be
necessary to see the om/peer objects as a thin layer providing
convenience rather than a full OR layer enforcing consistent
relationshops.
Actually while I was typing that last paragraph I had a thought about
this. Something that I've just implemented for a few of my generated
peers is a caching mechanism (using the GlobalCacheService), because
they are hit heavily at some points, and at the moment I haven't worried
about DB/cache mismatches because they are pretty much read only tables.
It might be a useful feature to provide a (disableable) caching layer as
part of the autogenerated om/peer code. Part of the job of this caching
layer would be to handle caching foreign objects, rather than caching
them in the business objects themselves. Then the business objects could
do a "real" DB select (potentially intercepted by the caching layer)
every time a foreign attribute/collection is requested.
Obviously this caching layer would need some considerable though to
consider all the access points to modifying the underlying DB to prevent
the DB and cache becoming out of step. And obviously it would only work
where the one webapp was the only app accessing the DB. However it would
allow the om/peer level to maintain consistency in the examples you give
if implemented properly.
What do you think?
Sean
--
Sean Legassick
[EMAIL PROTECTED]
Hombre soy, nada humano me puede ser ajeno
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
