What about using runtime byte-code enhancement, as you mentioned it, to extends classes to dynamically add properties for storing AKs, thus removing the need of AnonymousPersistentField ...
Guillaume -----Message d'origine----- De : Armin Waibel [mailto:[EMAIL PROTECTED] Envoy� : jeudi 22 avril 2004 15:01 � : OJB Users List Objet : Re: Problem with clearing cache Hi Guillaume,Brian, I think the anonymous key (AK) feature should be modified/rewriten because currently it is object identity based. This means you will loose all AK information when the object will be de-/serialized or copied. The upcoming two-level cache will do so and the OTM implementation too (and my "feeling" is that this will cause problems). The AK in conjunction with 1:1 references are always be save (I think), because when the AK information is lost, we can use the reference to re-create the AK information. > I'm willingfull to help refactoring this part, but i'd like to > have guidelines sorry I don't have any ideas (without byte-code enhancement ;-)) > if anonymous keys are integrated within the existing cache system, > but i have no ideas on how to do it. this will be difficult, because AK implementation does not know about the cache and the cache could be per class-descriptor, per connection or global. regards, Armin Guillaume Nodet wrote: > I use both anonymous PK's and FK's. But the use i do of anonymous > primary keys is limited to objects that belongs to collections of > main objects. Main objects have *real* primary keys and only > these ones are used directly in the broker (all collections are > prefetched) and cached. So i think that using anonymous pk's in > my case is safe (if my understanding is good, problems can arise > when using anonymous pk's in distributed environnments). > > So the main problem is the caching system > for anonymous keys (either pk or fk) : > * keys are kept in a cache specific to the field > * this cache can not be accessed by any means so no clear > is possible > * this cache can not be a per-broker cache > * anonymous persistent fields implementation > can not be extended or overriden > > I'm willingfull to help refactoring this part, but i'd like to > have guidelines on how to do it... > I think it would be great > if anonymous keys are integrated within the existing cache system, > but i have no ideas on how to do it. > > Guillaume > > > -----Message d'origine----- > De : Brian McCallister [mailto:[EMAIL PROTECTED] > Envoy� : jeudi 22 avril 2004 14:06 > � : OJB Users List > Objet : Re: Problem with clearing cache > > > Anonymous PK's are risky things -- I apologize for using them in the > original anonymous keys tutorial. Anonymous FK's are great, and not > using them is usually a bad ida in my opinion =) > > I don't think the anonymous PK issues you are having will be resolved > very soon, the anonymous key functionality wasn't really designed for > PK usage, but for FK usage. I completely feel that it would be good to > be able to use them for PK's as well, but my slate is full at the > moment with JDO stuff =( > > I don't know about everyone else. Any chance *you* want to dig into it? > ;-) > > -Brian > > On Apr 22, 2004, at 7:55 AM, Guillaume Nodet wrote: > > >>It also seems that cached anonymous keys are not removed from >>the cache when an object is deleted from database. >>Will these problems be solved, or should i try not to use >>anonymous keys ? >> >>Guillaume >> >>-----Message d'origine----- >>De : Guillaume Nodet [mailto:[EMAIL PROTECTED] >>Envoy� : mercredi 21 avril 2004 14:42 >>� : OJB Users List >>Objet : Problem with clearing cache >> >> >>I need to clear the ojb cache at some point in my program >>(namely after deleting all data in the database). >>The problem i have is that i use anonymous primary keys and >>the caches associated with the anonymous fields are not cleared. >>Would it be possible to had some mean of clearing these caches ? >> >>The problem is that at some time, i've got errors when inserting >>objects. I think that the key for the failing object is in cache >>but not in the database so when a foreign key references it, >>the insertion fails. >> >>Thanks, >>Guillaume Nodet >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
