First, thank you for sharing your finding.
However, there are quite a few critics to Castor JDO, in my opinion is only a personal programming styles. Also, some inaccurate information. Thomas ---------- "In your document, you wrote "Castor only implements Eager relationship". It is not true. A quarter of your document was written based on that assumption, so I am not commenting on that." Lazy loading of collection have been already implemented. See, D:\cvs\one\castor\build\doc\castor-one.html ------ "Note that the problem with lazy loading is not incidental but fundamental and so cannot easily be corrected in a future version" Lazy loading of collection have been already implemented. ----------- "Normally Castor accesses instance variables by Getters & Setters. But these are in fact useless, they cannot be used for validation logic and Castor cannot use them to detect updates. So best to declare fields <...direct="true">, as shown in Parent." The above statement is misleading. Castor can detect changes using both getter/setter and direct fields. Which one to use is purely programmatic style. I prefer getter/setter. Remember that fields are shadowed, methods are overridden. It really depends on what you want. ---------- "However, if the record does not exist db.load() throws an exception rather than just returning null which is a pain." I can't disagree more on this. If you really want a null, simply put the load() in another private method with a try/catch block in it. I prefer exception, because it is. -------- "By default Castor neither locks nor detects changes from other transactions" It is completely opposite. Castor, by default, detect concurrent changes. User can turn it off in field-by-field basis in the mapping file (ie, <field dirty="ignore"/>). Castor has it own memory locks. Each load()/queried() object are read-locked. During db.create(), a row is inserted right the way. And, it essentially locked the created row. ----- "However, attempts to update the row correctly cause an optimistic crash." I don't understand what you mean. ------ "Unlike a relational database, Castor requires you to declare each end of a relationship redundantly" It is corrected that Castor JDO required the data object be bi-direction "links". I won't compare relationship with "links", and certainly won't count it as redundant. -----Original Message----- >From: Anthony Berglas [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 06, 2001 10:09 AM >To: [EMAIL PROTECTED] >Subject: [castor-dev] Additional DOCUMENTATION and test cases (JDO) > >Hello All, > >I have attached the result of an evaluation of Castor which includes several >significant test cases, performance benchmarks, and most importantly >additional documentation of how Castor JDO actually works. I hope people >find this useful. > >All feedback and criticism most welcome. As I will be away for a few weeks >please be sure to CC any replies to my direct address above. > >I would like to take this opportunity to thank the Exolab team for providing >Castor. > >Regards, > >Anthony > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
