Re: MetadataManager.copyOfGlobalRepository() and transient fields in repository objects
Hi Andy, Andy Malakov wrote: Hello All, It looks like a bug: Class o.a.ojb.broker.metadata.MetadataManager.copyOfGlobalRepository() uses SerializationUtils.clone() to return a copy of OJB repository. At the same time some objects in repository graph have transient fields which become un-initialized (null) after the clone. For example, o.a.ojb.broker.metadata.fieldaccess.AnonymousPersistentField has fkCache map that will become null in clone, and will cause NullPointerException when get()/set() will be executed. Method copyOfGlobalRepository() is required for per-thread handling of metadata. you are right, it's a bug. Put this on my todo list. regards, Armin Thank you, Andy - 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]
RE: prefetch and autoRetreive
I sensed that, but I'm not sure the penalty for loading an object twice is is bad as the penalty I was getting. A lot of places in our code assume the object reference is loaded on a required relationship. One thread was prefetching and turned off auto-retrieve, then another came in and thought that was the right value and set it back to that. So from then on none of the objects had the relationship loaded and I got NullPointerException everywhere. I suppose that multiple loads could be more of an issue with the global cache, but with cache-per-broker I'm not sure if that's an issue. At least to me double-load isn't as big a deal as the NPE's. I had to discontinue using prefetch in the couple of places I was using it. (Not sure that's the worst thing anyway, since I don't know that it helped a whole lot.) John >= Original Message From Jakob Braeuchi <[EMAIL PROTECTED]> = >hi john, > > >John wrote: > >> Has there been any solution to this issue (OJB188)? This bit me in the butt, >> but of course it took quite a bit of digging and debugging to realize this is >> what was happening. Why exactly is the value changed while prefetching? >> > >auto-retrieve is disabled during prefetching of a relationship to avoid >loading the same obj multiple times. > >jakob > >> I have a patched version of OJB that was based on HEAD from the middle of >> August, so I haven't been able to update for a while (don't want to repatch). >> It seems that there have been some changes to OJB since then with regards to >> (proxy) prefetching, autoretrieve, etc, especially in how those are configured >> in the repository. Are these summarized anywhere? >> >> John Marshall >> Connectria >> >> >> = >> Date: Fri, 11 Jul 2003 18:19:33 +0200 >> From: Jakob Braeuchi <[EMAIL PROTECTED]> >> Subject: Potential problem with prefetch-relationships ? >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> >> hi theo, >> >> during prefetch auto-retrieve is disabled. when an other thread uses the >> relationship-desriptor it will find auto-retrive off. >> this is a known problem but i do not have a solution for it :( >> >> >> jakob >> >> Theo Niemeijer wrote: >> >> >>>Hi all, >>>I seemed to have stumbled on a potential problem with >>>the "prefetch relationship" option in PB query. >>> >>>After using prefetchRelationship for retrieval of big list of results, >>>and at the same time performing other queries, >>>I seemed to have lost the "auto-retrieve" attribute on >>>the collection descriptor. >>> >>>The result was that subsequent queries did not >>>retrieve that collection anymore, probably because the >>>"auto-retrieve" was disabled. >>> >>>The problem is quite hard to reproduce, but my guess is >>>that different threads modified the repository descriptor >>>in the wrong sequence, by means of the setCascadeRetrieve >>>method used in prepareRelationshipSettings. >>> >>>I might be wrong, because I simply do not oversee all aspects >>>of OJB. But am I right to view this as a potential problem >>>in "concurrency situations" like websites ? >>>I do not feel too comfortable that OJB makes these "temporary" >>>changes to the repository model. >>> >>>Cheers, >>> Theo Niemeijer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: prefetch and autoRetreive
I sensed that, but I'm not sure the penalty for loading an object twice is is bad as the penalty I was getting. A lot of places in our code assume the object reference is loaded on a required relationship. One thread was prefetching and turned off auto-retrieve, then another came in and thought that was the right value and set it back to that. So from then on none of the objects had the relationship loaded and I got NullPointerException everywhere. I suppose that multiple loads could be more of an issue with the global cache, but with cache-per-broker I'm not sure if that's an issue. At least to me double-load isn't as big a deal as the NPE's. I had to discontinue using prefetch in the couple of places I was using it. (Not sure that's the worst thing anyway, since I don't know that it helped a whole lot.) John >= Original Message From Jakob Braeuchi <[EMAIL PROTECTED]> = >hi john, > > >John wrote: > >> Has there been any solution to this issue (OJB188)? This bit me in the butt, >> but of course it took quite a bit of digging and debugging to realize this is >> what was happening. Why exactly is the value changed while prefetching? >> > >auto-retrieve is disabled during prefetching of a relationship to avoid >loading the same obj multiple times. > >jakob > >> I have a patched version of OJB that was based on HEAD from the middle of >> August, so I haven't been able to update for a while (don't want to repatch). >> It seems that there have been some changes to OJB since then with regards to >> (proxy) prefetching, autoretrieve, etc, especially in how those are configured >> in the repository. Are these summarized anywhere? >> >> John Marshall >> Connectria >> >> >> = >> Date: Fri, 11 Jul 2003 18:19:33 +0200 >> From: Jakob Braeuchi <[EMAIL PROTECTED]> >> Subject: Potential problem with prefetch-relationships ? >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> >> hi theo, >> >> during prefetch auto-retrieve is disabled. when an other thread uses the >> relationship-desriptor it will find auto-retrive off. >> this is a known problem but i do not have a solution for it :( >> >> >> jakob >> >> Theo Niemeijer wrote: >> >> >>>Hi all, >>>I seemed to have stumbled on a potential problem with >>>the "prefetch relationship" option in PB query. >>> >>>After using prefetchRelationship for retrieval of big list of results, >>>and at the same time performing other queries, >>>I seemed to have lost the "auto-retrieve" attribute on >>>the collection descriptor. >>> >>>The result was that subsequent queries did not >>>retrieve that collection anymore, probably because the >>>"auto-retrieve" was disabled. >>> >>>The problem is quite hard to reproduce, but my guess is >>>that different threads modified the repository descriptor >>>in the wrong sequence, by means of the setCascadeRetrieve >>>method used in prepareRelationshipSettings. >>> >>>I might be wrong, because I simply do not oversee all aspects >>>of OJB. But am I right to view this as a potential problem >>>in "concurrency situations" like websites ? >>>I do not feel too comfortable that OJB makes these "temporary" >>>changes to the repository model. >>> >>>Cheers, >>> Theo Niemeijer >> >> >> >> - >> 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]
RE: Auto create tables in the DB
Sorry, the cds just wraps a connection as a DataSource. Nothing fancy.
As for getting the connection, here's what I do. Don't know if it's the best
way.
John
/**
* Supports checkSchema. Connection needs to be closed via broker, so we
* need to proxy the connection and close the source when requested.
*/
public Connection getConnection() {
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
try {
Connection con =
broker.serviceConnectionManager().getConnection();
InvocationHandler handler = new ConnectionInvocationHandler(
broker, con );
Connection result = (Connection)
Proxy.newProxyInstance(Connection.class.getClassLoader(),
new Class[] { Connection.class },
handler);
return result;
} catch ( LookupException le ) {
throw new RuntimeException(le);
}
}
private static class ConnectionInvocationHandler implements
InvocationHandler {
private PersistenceBroker _broker;
private Connection _con;
private ConnectionInvocationHandler( PersistenceBroker broker,
Connection con ) {
_broker = broker;
_con = con;
}
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
Object result = null;
if ( "close".equals(method.getName()) ) {
System.out.println("closing connection on broker");
//Connection.close() returns void, leave result null
//don't commit - not in transaction
_broker.close();
} else {
result = method.invoke( _con, args );
}
return result;
}
} //ConnectionInvocationHandler
private static class ConnectionDataSource implements DataSource {
private Connection _cn;
public ConnectionDataSource( Connection cn ) {
_cn = cn;
}
/**
* @see javax.sql.DataSource#getConnection()
*/
public Connection getConnection() throws SQLException {
return _cn;
}
//all other methods throw SQLException("Not supported")
}
>= Original Message From Gus Heck <[EMAIL PROTECTED]> =
>For the moment I just implemented my own ConnectionDataSource, but I
>cant seem to get far enough to test it. I dont' seem to be able to get
>hold of a Connection object. Here's what I tried, (if anyone has a
>better way, I would really like to hear it:
>
>InputStream is =
>Thread.currentThread().getContextClassLoader().getResourceAsStream("project_s
chema.xml");
>Database db = null;
>try {
>DatabaseReader reader = new DatabaseReader();
>db = (Database) reader.parse( is );
>} catch (IntrospectionException ie) {
>System.out.println("Error creating DatabaseReader for
>project_schema.xml");
>} catch (IOException ioe ) {
>System.out.println("Error loading project_schema.xml");
>} catch (SAXException saxe ) {
>System.out.println("Error parsing project_schema.xml");
>}
>
>ConnectionFactoryFactory cff =
>ConnectionFactoryFactory.getInstance();
>ConnectionFactory cf = cff.createConnectionFactory();
>
>MetadataManager mm = MetadataManager.getInstance();
>ConnectionRepository cRepos = mm.connectionRepository();
>JdbcConnectionDescriptor descriptor = cRepos.getDescriptor(new
>PBKey("fdbcon"));
>
>System.out.println("descriptor = " + descriptor);
>
>Connection existing;
>try {
>existing = cf.lookupConnection(descriptor);
>} catch (LookupException le) {
>throw new RuntimeException("Failed looking up connection
>from descriptor.");
>}
>
>This however fails because the connection descriptor appears to return
>null for username and password...
>
>java.sql.SQLException: Invalid authorization specification, message
>from server: "Access denied for user: '[EMAIL PROTECTED]'
>(Using password: NO)"
>at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1825)
>at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1752)
>
>Furthermore, it seems that OJB is NOT respecting my settings in the
>database.xml file completely. Here is the descriptor:
>
> jcd-alias="fdbcon"
> default-connection="true" <-Notice this!
> platform="MySQL"
> jdbc-level="2.0"
> driver="org.gjt.mm.mysql.Driver"
> protocol="jdbc"
> subprotocol="mysql"
> dbalias="//localhost:3306/fdbtest2"
> username="This is, of course, something else in the deployed
>file"
> password="This is, of course, something else in the deployed
>file"
>eager-releas
Re: Betwixt bug as well it seems... (sigh)
Ok your recent check in fixed the test failing problem, and the newer betwixt code seesm to work just fine. (at least they work well enough to expose another bug in MY app :) ). The OJB issue with MetaDataManager.copyOfGlobalRepository() still exists (to my knowledge), but betwixt now seems to be doing what it should. Thanks for the help. -Gus Martin van den Bemt wrote: Hmm.. weird.. everything passes here using maven test, although I have an error in the test when running the test from Eclipse (a different one though and i18n related). I guess you are probably using ant, so I updated the build.xml from maven. Hope that helps. Mvgr, Martin On Mon, 2003-11-24 at 20:12, Gus Heck wrote: Hi Martin, Working on testing the latest betwixt (cvs) as suggested, and it seems that your tests don't pass at the moment I am still going to proceed and see if my issue is fixed, but thought I would pass this on: [EMAIL PROTECTED] betwixt]$ cat target/test-reports/TEST-org.apache.commons.betwixt.TestBeanReader.txt Testsuite: org.apache.commons.betwixt.TestBeanReader Tests run: 2, Failures: 1, Errors: 1, Time elapsed: 0.936 sec Testcase: testBeanWriter took 0.395 sec FAILED Is a CustomerBean junit.framework.AssertionFailedError: Is a CustomerBean at org.apache.commons.betwixt.TestBeanReader.testCustomer(TestBeanReader.java:196) at org.apache.commons.betwixt.TestBeanReader.testBeanWriter(TestBeanReader.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testBeanWriterTestcase: testWriteThenRead took 0.093 sec Caused an ERROR null java.lang.NullPointerException at org.apache.commons.betwixt.TestBeanReader.testWriteThenRead(TestBeanReader.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: [EMAIL PROTECTED] betwixt]$ -Gus Martin van den Bemt wrote: Hi Gus, Could you have a go at the latest betwixt build (just committed a fix to cvs, which sounds a bit similar to your situation). If that is still not working, it would be nice to have a testcase of some kind to make my life a bit easier (don't know if commons-sql moved to db commons, although it doesn't seem like it ?) I'll keep ojb-user on the cc, if that's ok (please keep commons-dev on the cc too,since I am not subscribed to ojb-user.. Mvgr, Martin On Fri, 2003-11-21 at 23:46, Gus Heck wrote: - 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]
RE: Collection of string
On Mon, 24 Nov 2003 [EMAIL PROTECTED] wrote: > Hello Thomas, > > > -Original Message- > > From: Mahler Thomas [mailto:[EMAIL PROTECTED] > > > 1. Define your DB coulm as VARCHAR. > > 2. in the repository_user.xml you set > > conversion="org.apache.ojb.broker.accesslayer. > > conversions.StringVector2Varch arFieldConversion" > > 3. That's all! > > > > All strings of your Vector get concatened and written to the > > VARCHAR column > > in human readable form. > > that is nice only for collections of bounded size of Strings > of bounded lengths. Otherwise you get troubles with > the column length of the database, don't you? > Mapping to BLOB/CLOB is certainly better here (using appropriate conversions), and CLOB might be human readable, but as I understand the problem, Eric wanted to have each string in a separate row in the database ?! Can this be handled via a row-reader for class String ? Eric, can you perhaps give some details on how Hibernate handles this ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Collection of string
Hello Thomas, > -Original Message- > From: Mahler Thomas [mailto:[EMAIL PROTECTED] > 1. Define your DB coulm as VARCHAR. > 2. in the repository_user.xml you set > conversion="org.apache.ojb.broker.accesslayer. > conversions.StringVector2Varch arFieldConversion" > 3. That's all! > > All strings of your Vector get concatened and written to the > VARCHAR column > in human readable form. that is nice only for collections of bounded size of Strings of bounded lengths. Otherwise you get troubles with the column length of the database, don't you? Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Betwixt bug as well it seems... (sigh)
Hi Martin, Working on testing the latest betwixt (cvs) as suggested, and it seems that your tests don't pass at the moment I am still going to proceed and see if my issue is fixed, but thought I would pass this on: [EMAIL PROTECTED] betwixt]$ cat target/test-reports/TEST-org.apache.commons.betwixt.TestBeanReader.txt Testsuite: org.apache.commons.betwixt.TestBeanReader Tests run: 2, Failures: 1, Errors: 1, Time elapsed: 0.936 sec Testcase: testBeanWriter took 0.395 sec FAILED Is a CustomerBean junit.framework.AssertionFailedError: Is a CustomerBean at org.apache.commons.betwixt.TestBeanReader.testCustomer(TestBeanReader.java:196) at org.apache.commons.betwixt.TestBeanReader.testBeanWriter(TestBeanReader.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testBeanWriterTestcase: testWriteThenRead took 0.093 sec Caused an ERROR null java.lang.NullPointerException at org.apache.commons.betwixt.TestBeanReader.testWriteThenRead(TestBeanReader.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: [EMAIL PROTECTED] betwixt]$ -Gus Martin van den Bemt wrote: Hi Gus, Could you have a go at the latest betwixt build (just committed a fix to cvs, which sounds a bit similar to your situation). If that is still not working, it would be nice to have a testcase of some kind to make my life a bit easier (don't know if commons-sql moved to db commons, although it doesn't seem like it ?) I'll keep ojb-user on the cc, if that's ok (please keep commons-dev on the cc too,since I am not subscribed to ojb-user.. Mvgr, Martin On Fri, 2003-11-21 at 23:46, Gus Heck wrote: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
another tool for OJB...
tested with MySQL and looking for others to review & suggest. We have been getting pretty frustrated at having to setup OJB, rewrite the repository and java files every time an architecture change is made. We sat down and tried to come up with a 'nice' way of doing it. the factors considered were: versioning of the schema regeneration of the SQL schema / database initialization non-clobbering of code non-clobbering of manual repository.xml additions. obvious compile errors when schema changes result in OBJ object definition changes portability AutoBaseJDBCSchemaDumper: converts JDBC's DatabaseMetaData to XML it annotates some fields to make xsl stuff easier AutoBaseInterface.xsl: this creates a java file which can be used for proxy, etc. AutoBaseObject.xsl: this creates a java file which can be subclasses / instantiated AutoBaseRepository.xsl: this creates a repository.xml fragment AutoBaseSQL.xsl: this creates a SQL script of create tables, etc [ not done yet ] http://www.pyerotechnics.com/products/AutoBase.tgz -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner & Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Collection of string
That's what I thought, untill I realised that eric's strings are stored as rows in a table, as opposed to a single column. Cheers, Charles. > -Original Message- > From: Mahler Thomas [mailto:[EMAIL PROTECTED] > Sent: 24 November 2003 16:31 > To: 'OJB Users List' > Subject: RE: Collection of string > > > > Hi there is a very nice feature in OJB to handle this: > > 1. Define your DB coulm as VARCHAR. > 2. in the repository_user.xml you set > conversion="org.apache.ojb.broker.accesslayer.conversions.Stri > ngVector2Varch > arFieldConversion" > 3. That's all! > > All strings of your Vector get concatened and written to the > VARCHAR column > in human readable form. > > cu, > Thomas > > > -Original Message- > > From: eric barbe [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 24, 2003 3:27 PM > > To: OJB Users List > > Subject: RE: Collection of string > > > > > > Yes, you're right, but what do you think about Hibernate > > witch seems to do > > this very simply ? > > > > Eric > > > > -Message d'origine- > > De : Thomas Dudziak [mailto:[EMAIL PROTECTED] > > Envoye : lundi 24 novembre 2003 11:01 > > A : OJB Users List > > Objet : RE: Collection of string > > > > > > > > > > On Mon, 24 Nov 2003, eric barbe wrote: > > > > > Hi Thomas, > > > > > > Thanks for your help. > > > I thought about this solution, but honestly, it is not very > > beautiful. > > > They are no other ways ? > > > Is it possible to hope that OJB will do this easily in a > > future release ? > > > > Thats not so much a problem of OJB but a design decision of > > Java. Strings > > are immutable after creation (value objects). OJB can work with all > > objects that are changeable after creation and have a default > > constructor. > > Actually, that is not quite correct. It seems that in the > current CVS > > version you can define a factory class and method to create > objects so > > there is no need for the default constructor anymore. So in > > theory, you > > might be able to use strings after all, using a combination of > > factory-class/method and a custom row-reader for the string objects > > (I'm not an expert of row-readers so this might be wrong). > But this is > > probably not quite an elegant solution. > > > > As for the "beauty" of the solution, that depends on your > > application, or > > more precisely, on how the strings are used. If there is > functionality > > that can be put into the wrapper objects (say, conversion > > from exceptions, > > serialization to/from XML etc.) then they can actually make > > the design of > > your system more beautiful. > > > > Tom > > > > > > > - > > 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] > > ___ HPD Software Ltd. - Helping Business Finance Business Email terms and conditions: www.hpdsoftware.com/disclaimer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Collection of string
Hi there is a very nice feature in OJB to handle this: 1. Define your DB coulm as VARCHAR. 2. in the repository_user.xml you set conversion="org.apache.ojb.broker.accesslayer.conversions.StringVector2Varch arFieldConversion" 3. That's all! All strings of your Vector get concatened and written to the VARCHAR column in human readable form. cu, Thomas > -Original Message- > From: eric barbe [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2003 3:27 PM > To: OJB Users List > Subject: RE: Collection of string > > > Yes, you're right, but what do you think about Hibernate > witch seems to do > this very simply ? > > Eric > > -Message d'origine- > De : Thomas Dudziak [mailto:[EMAIL PROTECTED] > Envoye : lundi 24 novembre 2003 11:01 > A : OJB Users List > Objet : RE: Collection of string > > > > > On Mon, 24 Nov 2003, eric barbe wrote: > > > Hi Thomas, > > > > Thanks for your help. > > I thought about this solution, but honestly, it is not very > beautiful. > > They are no other ways ? > > Is it possible to hope that OJB will do this easily in a > future release ? > > Thats not so much a problem of OJB but a design decision of > Java. Strings > are immutable after creation (value objects). OJB can work with all > objects that are changeable after creation and have a default > constructor. > Actually, that is not quite correct. It seems that in the current CVS > version you can define a factory class and method to create objects so > there is no need for the default constructor anymore. So in > theory, you > might be able to use strings after all, using a combination of > factory-class/method and a custom row-reader for the string objects > (I'm not an expert of row-readers so this might be wrong). But this is > probably not quite an elegant solution. > > As for the "beauty" of the solution, that depends on your > application, or > more precisely, on how the strings are used. If there is functionality > that can be put into the wrapper objects (say, conversion > from exceptions, > serialization to/from XML etc.) then they can actually make > the design of > your system more beautiful. > > Tom > > > - > 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]
RE: Persistence frameworks
Hi Max, YAC (Yet another clarification): > >> > >> EH!!? Huh! explain please ;) How can you synchronize/lock > in memory > >> without > >> locking or synchronization mechanisms ?! > >> > > > > You are right, we do the lock management with a pluggable component > > called LockManager. > > I just wanted to say that we are not relying on java > *language* features > > like synchronized blocks. > > So - how do you synchronize without it ? If you are not using > language features, > what are you using ? The database ? It depends on the Lockmanager Implementation. The default implementation uses a Hashtable to store Lock objects in memory. If a transaction tries to obtain a lock we check in the hashtable if there is already a Lock entry for this Object. If there is no lock than its OK to obtain a lock on this object. If there is already a lock, it depends on the type of the existing lock (READ, WRITE) and the isolation level semantics if it's ok to obtain an additional lock. The Semantics of the isolation levels is defined here: http://db.apache.org/ojb/lockmanager.html. If you want to use transaction synchronization accross multiple JVMs (possibly running on different physical machines) you simply use a persistent LockMap implementation. The persistent LockMap uses a database table (OJB_LOCKENTRY)to store locks. To make locks persistent allows to make them visible to all connected ODMG clients. A different solution could be to provide a separate LockManager server that does not use a database table, but any other means to keep the locks. So far no user requested it. And using a db table for this purpose has not been a problem so far. cu, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Collection of string
Yes, you're right, but what do you think about Hibernate witch seems to do this very simply ? Eric -Message d'origine- De : Thomas Dudziak [mailto:[EMAIL PROTECTED] Envoye : lundi 24 novembre 2003 11:01 A : OJB Users List Objet : RE: Collection of string On Mon, 24 Nov 2003, eric barbe wrote: > Hi Thomas, > > Thanks for your help. > I thought about this solution, but honestly, it is not very beautiful. > They are no other ways ? > Is it possible to hope that OJB will do this easily in a future release ? Thats not so much a problem of OJB but a design decision of Java. Strings are immutable after creation (value objects). OJB can work with all objects that are changeable after creation and have a default constructor. Actually, that is not quite correct. It seems that in the current CVS version you can define a factory class and method to create objects so there is no need for the default constructor anymore. So in theory, you might be able to use strings after all, using a combination of factory-class/method and a custom row-reader for the string objects (I'm not an expert of row-readers so this might be wrong). But this is probably not quite an elegant solution. As for the "beauty" of the solution, that depends on your application, or more precisely, on how the strings are used. If there is functionality that can be put into the wrapper objects (say, conversion from exceptions, serialization to/from XML etc.) then they can actually make the design of your system more beautiful. Tom - 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]
RE: Collection of string
On Mon, 24 Nov 2003, eric barbe wrote: > Hi Thomas, > > Thanks for your help. > I thought about this solution, but honestly, it is not very beautiful. > They are no other ways ? > Is it possible to hope that OJB will do this easily in a future release ? Thats not so much a problem of OJB but a design decision of Java. Strings are immutable after creation (value objects). OJB can work with all objects that are changeable after creation and have a default constructor. Actually, that is not quite correct. It seems that in the current CVS version you can define a factory class and method to create objects so there is no need for the default constructor anymore. So in theory, you might be able to use strings after all, using a combination of factory-class/method and a custom row-reader for the string objects (I'm not an expert of row-readers so this might be wrong). But this is probably not quite an elegant solution. As for the "beauty" of the solution, that depends on your application, or more precisely, on how the strings are used. If there is functionality that can be put into the wrapper objects (say, conversion from exceptions, serialization to/from XML etc.) then they can actually make the design of your system more beautiful. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Stored procedures in MS SQL
Ron, > I just submitted to the OJB-dev mailing list an update to the documentation > related to OJB's support for stored procedures. Look for it to appear on > the OJB website sometime soon. Thanks a million. This is exactly what I asked. -- Sergey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Collection of string
Hi Thomas,
Thanks for your help.
I thought about this solution, but honestly, it is not very beautiful.
They are no other ways ?
Is it possible to hope that OJB will do this easily in a future release ?
Thanks,
Regards
Eric
-Message d'origine-
De : Thomas Dudziak [mailto:[EMAIL PROTECTED]
Envoye : vendredi 21 novembre 2003 18:15
A : OJB Users List
Objet : RE: Collection of string
On Fri, 21 Nov 2003, eric barbe wrote:
> Hi,
>
> Yes, I need to use this table on reporting applications that do not use
OJB.
> This fields must be readable.
>
The string class itself won't work as an existing string object cannot be
changed anymore (upon loading OJB creates the object using the no-argument
constructor and the sets the fields). So I suggest that you use a wrapper
class in your collection such as:
class Value
{
private Integer id;
private String value;
...
public Value()
{}
public void setValue(String value)
{
this.value = value;
}
public String getValue()
{
return value;
}
...
}
(You don't really need the id here, an anonymous primarykey field would
also work).
Then you simply define a class descriptor for this class in
your repository descriptor.
Tom
-
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]
Re: Betwixt bug as well it seems... (sigh)
Hi Gus,
Could you have a go at the latest betwixt build (just committed a fix to
cvs, which sounds a bit similar to your situation). If that is still not
working, it would be nice to have a testcase of some kind to make my
life a bit easier (don't know if commons-sql moved to db commons,
although it doesn't seem like it ?)
I'll keep ojb-user on the cc, if that's ok (please keep commons-dev on
the cc too,since I am not subscribed to ojb-user..
Mvgr,
Martin
On Fri, 2003-11-21 at 23:46, Gus Heck wrote:
> In light of this, I decided to enable further development by setting the
> missing username and password for now until the bug can be resolved.
> When I did I got more funny results that look very much like a bug...
> The following code:
>
> InputStream is =
> Thread.currentThread().getContextClassLoader().getResourceAsStream("project_schema.xml");
> Database db = null;
> try {
> DatabaseReader reader = new DatabaseReader();
> db = (Database) reader.parse( is );
> } catch (IntrospectionException ie) {
> throw new RuntimeException("Error creating DatabaseReader
> for project_schema.xml");
> } catch (IOException ioe ) {
> throw new RuntimeException("Error loading project_schema.xml");
> } catch (SAXException saxe ) {
> throw new RuntimeException("Error parsing project_schema.xml");
> }
>
> System.out.println(db);
> for (Iterator iter = db.getTables().iterator();iter.hasNext();) {
> org.apache.commons.sql.model.Table t
> = (org.apache.commons.sql.model.Table) iter.next();
> System.out.println(t);
> System.out.println(t.getName());
> }
>
> produces the following output:
>
> [EMAIL PROTECTED];tableCount=1]
> [EMAIL PROTECTED]
> null
>
> The number of tables is correct, but I feel certain that it should not
> be named null giventhe following project_schema.xml (still in defaults
> for the field sizes... I'll deal with that after I write something to
> the database successfully):
>
>
>
> javaName="id"
> type="INTEGER"
> primaryKey="true"
> required="true"
> />
> javaName="country"
> type="VARCHAR"
> size="24"
> />
> javaName="stateOrRegion"
> type="VARCHAR"
> size="24"
> />
> javaName="subRegion"
> type="VARCHAR"
> size="24"
> />
> javaName="city"
> type="VARCHAR"
> size="24"
> />
>
>
>
> Sadly it appears that commons-sql's DatabaseReader is just a fairly
> simple extension of a betwixt BeanReader...
>
> package org.apache.commons.sql.io;
>
> import java.beans.IntrospectionException;
>
> import org.apache.commons.betwixt.XMLIntrospector;
> import org.apache.commons.betwixt.io.BeanReader;
> import org.apache.commons.betwixt.strategy.HyphenatedNameMapper;
> import org.apache.commons.sql.model.Database;
>
> /**
> * This class parsers XML and creates a fully populated Database bean.
> * This class is-a Digester and so can support configuration via custom
> rules.
> *
> * @author mailto:[EMAIL PROTECTED]">James Strachan
> * @version $Revision: 1.14 $
> */
> public class DatabaseReader extends BeanReader {
>
> public DatabaseReader() throws IntrospectionException {
> setXMLIntrospector( newXMLIntrospector() );
> registerBeanClass(Database.class);
> }
>
> /**
> * A factory method to create the default introspector used to turn
> * the Database object model into XML
> */
> protected static XMLIntrospector newXMLIntrospector() {
> XMLIntrospector introspector = new XMLIntrospector();
>
> // configure the style of the XML, to brief and attribute based
> introspector.setAttributesForPrimitives(true);
> introspector.setWrapCollectionsInElement(false);
>
> // set the mixed case name mapper
> introspector.setElementNameMapper(new HyphenatedNameMapper());
> //introspector.setElementNameMapper(new DecapitalizeNameMapper());
>
> return introspector;
> }
> }
>
>
> and so this is probably a betwixt bug. I hope someone who understands
> betwixt can verify this (hence the cross post to commons-dev).
>
> -Gus
>
>
>
> Andy Malakov wrote:
>
> >Hello All,
> >
> >It looks like a bug:
> >
> >Class o.a.ojb.broker.metadata.MetadataManager.copyOfGlobalRepository() uses
> >SerializationUtils.clone() to return a copy of OJB
> >repository. At the same time some objects in repository graph have transient fields
> >which become un-initialized (null) after the
> >clone.
> >
> >For example, o.a.ojb.broker.metadata.fieldaccess.AnonymousPersiste
RE: Stored procedures in MS SQL
Sergey -- I just submitted to the OJB-dev mailing list an update to the documentation related to OJB's support for stored procedures. Look for it to appear on the OJB website sometime soon. Ron Gallagher Atlanta, GA [EMAIL PROTECTED] -Original Message- From: Sergey V. Oudaltsov [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 10:29 AM To: OJB Users List Subject: RE: Stored procedures in MS SQL > I don't think that the current documentation was meant to imply that > it only works for Oracle, however, the docs are out of sync with CVS > at the moment. OJB CVS has support for using repository.xml to define > sp's for insert, update, and delete of objects. Well, the question is how stable is CVS now - and when could we expect the version supporting stored procs? Week, month, year? I don't mind trying CVS - but I have to be sure the release of our project will have some stable version of OJB to ship with. > If you can't/do not wish to get CVS code, you should still be able to > make it work with MS SQL using the current documentation, just > implement your stored procedures as you would normally and ignore the > Oracle-specific parts of the docs. Well, current documentation only explains some steps people taken to support Oracle stored procs (in some package com.xxx:) - not even the existing support in OJB. -- Sergey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: confused about how to port some sql queries...
Jason --
For my answer, I'll assume that you have a class-descriptor for the class
"Timeclock" that is 'mapped' to the 'timeclock' table, and that this
class-descriptor has the following field-descriptors
attributeName mappedToColumn
= ==
tSin tsin
refEmployee ref_employee
tsOut tsout
With those assumptions, here's how you would accomplish your query:
// Assemble the criteria
Criteria criteria = new Criteria();
criteria.addEqualTo("refEmployee",someValueForRefEmployee);
criteria.addEqualTo("tsOut",someValueForTsOut);
// What columns should be included?
String columns[] = new String[1]{"min(tSin)"};
ReportQueryByCriteria query =
QueryFactory.newReportQuery(Timeclock.class,columns,criteria,true);
The last argument (true in my example) tell OJB whether or not you want
distinct rows returned. Setting it to true causes OJB to insert the
DISTINCT keyword in the generated sql.
As far as the 'targetClass' is concerned, this identifies the
class-descriptor that is the basis for which the various attributes (i.e.
"refEmployee", "tsOut" and "tSin") that are found in the criteria/column
list are resolved to actual table/column names.
HTH
Ron Gallagher
Atlanta, GA
[EMAIL PROTECTED]
-Original Message-
From: Jason Pyeron [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 22, 2003 9:03 PM
To: OJB Users List
Subject: confused about how to port some sql queries...
I have a prepared statement like so:
"SELECT min(tsin) FROM timeclock WHERE ref_employee= ? AND tsout=0;"
I use this to decide what to query next, it sounds like I should use the
"report" feature in OJB but I have no idea how.
I looked at
ReportQueryByCriteria(java.lang.Class targetClass, java.lang.String[]
columns, Criteria criteria)
what is this targetClass?
Sincerely,
Jason Pyeron
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Partner & Sr. Manager Pyerotechnics Development, Inc. -
- +1 (443) 451-2697 500 West University Parkway #1S -
- +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.
-
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]
RE: confused about how to port some sql queries...
Jason --
For my answer, I'll assume that you have a class-descriptor for the class
"Timeclock" that is 'mapped' to the 'timeclock' table, and that this
class-descriptor has the following field-descriptors
attributeName mappedToColumn
= ==
tSin tsin
refEmployee ref_employee
tsOut tsout
With those assumptions, here's how you would accomplish your query:
// Assemble the criteria
Criteria criteria = new Criteria();
criteria.addEqualTo("refEmployee",someValueForRefEmployee);
criteria.addEqualTo("tsOut",someValueForTsOut);
// What columns should be included?
String columns[] = new String[1]{"min(tSin)"};
ReportQueryByCriteria query =
QueryFactory.newReportQuery(Timeclock.class,columns,criteria,true);
The last argument (true in my example) tell OJB whether or not you want
distinct rows returned. Setting it to true causes OJB to insert the
DISTINCT keyword in the generated sql.
As far as the 'targetClass' is concerned, this identifies the
class-descriptor that is the basis for which the various attributes (i.e.
"refEmployee", "tsOut" and "tSin") that are found in the criteria/column
list are resolved to actual table/column names.
HTH
Ron Gallagher
Atlanta, GA
[EMAIL PROTECTED]
-Original Message-
From: Jason Pyeron [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 22, 2003 9:03 PM
To: OJB Users List
Subject: confused about how to port some sql queries...
I have a prepared statement like so:
"SELECT min(tsin) FROM timeclock WHERE ref_employee= ? AND tsout=0;"
I use this to decide what to query next, it sounds like I should use the
"report" feature in OJB but I have no idea how.
I looked at
ReportQueryByCriteria(java.lang.Class targetClass, java.lang.String[]
columns, Criteria criteria)
what is this targetClass?
Sincerely,
Jason Pyeron
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron http://www.pyerotechnics.com -
- Partner & Sr. Manager Pyerotechnics Development, Inc. -
- +1 (443) 451-2697 500 West University Parkway #1S -
- +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information. If you
have received it in error, purge the message from your system and
notify the sender immediately. Any other use of the email by you
is prohibited.
-
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]
Re: Persistence frameworks
Hi Thomas ;) Well, now you do ;) Hibernate does have an ODMG compliant implementation and does not have an extra tableas we understand the ODMG spec, the "store 'everything'" feature is not required to be ODMG compliant. If an OJB user chooses not to use the "store everything" collections, he wont't have to create the DList tables! OJB/ODMG has full support for using ordinary (i.e foreign key based) 1:n and m:n collections. But if a user wants to use full fledged "store everything" maps and collections he can do so by using the special tables. IMHO this freedom of choice is a plus for OJB and not a disatvantage! Correct, never claimed otherwise. Hibernate just focus more on practical usable stuff than less practical stuff ;) What part of the ODMG spec makes you believe that "store everything" is not mandatory for DList & co? Here you are hitting my limits ;) I don't know the ODMG spec by heart - but i'll see if I can dig it out ;) Another reason: The named roots concept. AFAIK Hibernate implements named roots with a special persistent class "Name". The idea of your "Name" class is very close to the OJB "NamedRootsEntry". They both provide a mechanism to contain a pointer to "everything". So for the Named roots you agree that ODMG requires pointers to everything but for DCollections you don't? Yes - Our Name class supports naming for persistent classes, not for "everything" Another thing that I don't understand yet: According to the ODMG spec the Name instances must be stored somewhere to be persistent. Where do you store those Name instances? I see there is a "Name.hbm.xml". Does this mean the Name instances are persisted to the Database? Yes they are. But my problem with OJB storing stuff in the db is regarding the locking mechanismsyou store "locks" in the db, right ? Not just "data". I guess we again need more clarifactions ;-) yes ;) cu, thomas So, I'm not exactly sure why you need those extra tables for synchronizing information that the database already has elsewhere (at least that is how I see that information). (but again that depends on what you mean exactly by synchronized transactions across a cluster) The special thing about OJB object level transaction is that they entirely kept on the java object level. So if an OJB ODMG transaction locks an object there is no database row lock ! Instead OJB uses an object level Lock manager. If you you are working in a single VM it's easy to work with a hashtable to keep the locks. If you are running on a cluster you need a LockManager that maintains the locks for all JVMs in the cluster. The current LockManager implementation uses a database table to hold the lockentries. As the LockManager is pluggable user can implement their own stuff if they don't like to keep an extra table. Ok (but this stuff is really not needed for most enterprise applications IMHO) Best regards, Max - 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]
Re: Persistence frameworks
Thomas Mahler wrote: Hi again Max, OJB manages the locking of lazy objects and Collection by a deferred locking mechanism. We are not using database mechanism for locking (e.g. row level locking) but our own LockManager mechanism. We are not using any JVM locking or synchronization mechanisms! EH!!? Huh! explain please ;) How can you synchronize/lock in memory without locking or synchronization mechanisms ?! You are right, we do the lock management with a pluggable component called LockManager. I just wanted to say that we are not relying on java *language* features like synchronized blocks. So - how do you synchronize without it ? If you are not using language features, what are you using ? The database ? As I understand it, OJB handles it by doing locking in JVM but this changes the database transaction isolation semantics You are right, OJB is able to provide Isolation levels for Object Transactions that are completely independ of the database transaction isolation! And that is BAD from our view ;) It's totally ok that OJB want to provide this feature, but it really requires expert usage to use and is not simple and safe per default. I think separating object level transactions from underlying db transactions is one of the greatest features in OJB! In my view: A nice feature but not a necessity. (but again I think we hit what is different between Hibernate and OJB Hibernate wants to be good at storing/retreiving stuff form a RDBMS mainly through jdbc/sql... OBJ want's to be good at everything persistabletwo different views, two different goals and two different solutions. People just need to be aware of this - many times people just want to store stuff in a RDMS and start use OJB's advanced/complex stuff even though they don't need it (and where I think Hibernate fits best)...and similar people uses Hibernate for high level object transactions yada yada where it does not fit in well. By doing this you can treat transactions as normal objects and transport complete transactions (with all affected objects) from one JVM to another. You could even store a snapshot of a complete transaction in the DB. after sone time you can reactivate it and continue it. Well - ain't that "just" a serialization of the java objects representing the "transaction" ? How will you do this if object transactions are tightly coupled with jdbc resources? We don't ;) but remember that our Session concept does not need to be bound by a JDBC transaction - it is just recommended. A session can be disconnected and reconnected to a Connection - and that is very usefull when using the session as a "work-holder". Yes - and we also much more prefer optimistic locking than use database level locking (but we support both and we think the database is much better to perform synchronization of data than any client-side synchronization) The LockManager is not necessarily a client side component. It can well be a server side component. This archtitecure works well even for the largest object oriented datastores: http://www.slac.stanford.edu/slac/media-info/20020412/database.htmlhttp://www.slac.stanford.edu/slac/media-info/20020412/database.html. By client-side I meant client in respect to the database - not in respect to OJB. The OJB solution does scale well. The LockManager implementation is very simple and so the overhead is not a problem. Well - the ODMG implementation is much slower than the PB Api in your own tests, right? The Hibernate core's speed is comparable to the PB API + small overhead when using locking... and that is faster in the OJB ODMG implementationso somewhere there is a bigger overhead somewhere ;) OJB/ODMG is not yet as fast as we would like it to be, granted. We have found several performance hotspots so far. But AFAIK they were not related to the lockmanagement. Ok - but lockmanagement is not the only thing that complicates ODMG ;) cu, Thomas later, Max Our LockManager architecture uses the same concepts as the lock service of highly scalable OO databases like Objectivity. cu, Thomas > There is also no way to clear cache other than nullifing the Session which also leads to the lazy collection problem above. This is all probably not a problem if you load and release all data, including lookup data, with each use case e.g. unit of work. I was also dissapointed that there is no mechanism to synchronize the cache with recent commits; Is that not what session.refresh() is for ? (or do you want a session wide refresh() method? - that would be slow!?!) another reason you always have to close the Session because it's the only way to remove stale cache and get up to date db data. Again - you could use e.g. session.clear() for removing stale data... Thanks for the comments and best regards, Max -Original Message- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, November 17, 2003 4:53 AM To: 'OJB Users List' Sub
Re: Persistence frameworks
LAURENT Stephane wrote: Hi, I'm just a (very happy !) OJB (PB) user. For me, the biggest difference between OJB and Hibernate is the query generation. I generaly have to retrieve : - small collections of simples objects (mapped to 1 or 2 tables) - more complexes objects(3 or 4 level of 1..n or n..n relations) retrieved by ID. For me, OJB is the best because I can't ask database with a 6 or 7 joined table query. Eh - what do you mean by this ? OBJ is best because it *can't* do X ? (is that a mistype or me not getting it ? ;) /max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
