Hi Werner, Yes, thanks for the clarification. The documentation gives you four options: no cache, count-limited, time-limited and unlimited. I had actually set the cache-type to the latter, unlimited.
Anyway, thanks again. John -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 21, 2006 03:29 AM To: [email protected]; [EMAIL PROTECTED] Subject: RE: [castor-user] BIGINT Support in Castor Thanks, John, for letting us know that you managed to solve your problems. Having said that, let me just address one of the issues mentioned below. As shown in the documentation for "long transactions", one needs to implement the TimeStampable interface to be able to use successfully e.g. the Database.update() method (which is what you have done). Internally, Castor needs to remember any object (that implements TimeStampable) that has been loaded as part of a transaction, so that it can check for any modifications to its content when passing this object to Datbase.update(). For this task, Castor JDO uses its caches. This implies that the (original) object in question should be available in the caches when performing the Database.update(). Unfortunately, there's cache types like 'count-limited' and 'time-limited' where this might not be the case, as the object might be dropped from the cache as a result of the cache's policy. Please note that using no cache at all defaults to using a 'count-limited' cache with an initial size of 100 (I believe). I hope this clarifies a few things related to the use of long transactions. Regards Werner ________________________________ From: John Greene [mailto:[EMAIL PROTECTED] Sent: Montag, 20. Februar 2006 22:50 To: Castor User Subject: FW: [castor-user] BIGINT Support in Castor I was able to sort this issue. When you implement TimeStampable two methods need to be overidden: public void jdoSetTimeStamp(long l) { setTimeStamp(l); } public long jdoGetTimeStamp() { return getTimeStamp(); } Since the runtime error message was complaining about the getTimeStamp method not available, I add two additional methods: public long getTimeStamp() { return timeStamp; } public void setTimeStamp(long _timeStamp) { this.timeStamp = _timeStamp; } Another issue was that I had defimed in my Mapping Table the IDENTITY as "BookTitle" as Varchar. If I wanted to change the book title I got another titel, using the UPDATE command I got a runtime error relating to the TimeStamp no longer in cache. But this is no longer a problem since I load the object and apply the commit command. regards John. -----Original Message----- From: John Greene [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 12:16 PM To: [email protected] Subject: RE: [castor-user] BIGINT Support in Castor Hi Werner, Yes, I agree that it should work as is. I'd like to run a few more test at my end first; if I continue to hit a "brick wall" I'll raise a new issue. regards John -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 02:44 AM To: [email protected]; [EMAIL PROTECTED] Subject: RE: [castor-user] BIGINT Support in Castor John, That should work out of the box. Can you please - as already indicated - open a new issue at http://jira.codehaus.org/browse/CASTOR and attach a stripped down sample that shows your problem. Thanks Werner ________________________________ From: John Greene [mailto:[EMAIL PROTECTED] Sent: Dienstag, 14. Februar 2006 22:32 To: [email protected] Subject: RE: [castor-user] BIGINT Support in Castor Thanks for the input. I am implementing "TimeStampable" which returns a type "long". public class Student implements TimeStampable { ......... public void jdoSetTimeStamp(long l) { timeStamp = l; } public long jdoGetTimeStamp() { return timeStamp; } } As you have said derby support "bigint" not "long" data type. But in my mapping file I did the mapping as follows:.......... <field name="timestamp" type="long"> <sql name="timestamp" type="bigint"/> </field> John. -----Original Message----- From: Brian Schlining [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 12:07 PM To: [email protected] Subject: Re: [castor-user] BIGINT Support in Castor I have a castor app that I've tested against both Derby and SQL Server. All the primary keys are bigints and the app works fine against both databases. The Castor mapping can be found at http://cvs.sourceforge.net/viewcvs.py/vars/vars/resources/conf/annotatio n_mapping.xml?view=markup The derby DDL is at http://cvs.sourceforge.net/viewcvs.py/vars/vars/src/sql/derby/vars.ddl?v iew=markup Cheers B Hi Werner, Quick question, does Castor support the sql type "BIGINT "? My Derby database uses type "BIGINT" intead of "long" Reported Run-time error: org.exolab.castor.mapping.MappingException: Nested error: org.exolab.castor.mapping.MappingException: The SQL type BIGINT is not supported in this release ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer [EMAIL PROTECTED] (831)775-1855 http://www.mbari.org/staff/brian ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] ------------------------------------------------- ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
