I have a small working example of the Java mail API working.. I will start in on building the JNDI/LDAP stuff...
ray -----Original Message----- From: Scott Howlett Sent: Monday, January 20, 2003 11:32 AM To: [EMAIL PROTECTED] Subject: OJB 0.9.8 issues and workarounds Hello, I've been playing with OJB 0.9.8 (just using the PersistenceBroker API) for the past few days. Here are a few gotchas I found, and the workarounds I've come up with: 1. setStartIndex and setEndIndex don't do anything Workaround (PostgreSQL-specific): Write a new SqlStatementGenerator that extends SqlGeneratorDefaultImpl. Override getSelectStatement and getPrepatedSelectStatement to add " OFFSET xxx LIMIT xxx" to the end of the statement if startAtIndex or endAtIndex is specified. By the way, there seems to be an inconsistency in the documentation - startAtEndex and endAtEndex are initialized to 0, but the javadoc for Query.setStartIndex() / setEndIndex() states that the "ignore cursor control" constant is -1. 2. PersistenceBrokerFactory.setDefaultPersistenceBroker() should be static, but isn't. Workaround: call PersistenceBrokerFactoryFactory.instance().setDefaultPersistenceBroker() instead. 3. If you provide a mapping for an object that includes foreign key attributes as well as reference objects related to those attributes, and you just update the foreign key, when you store the object your update will be clobbered because OJB first resets all foreign keys from the reference object identities. Workaround: call persistenceBroker.retrieveAllReferences() on the object prior to storing it so that any reference objects will be reset based on your foreign keys. 4. Sometimes an INNER JOIN is used when a LEFT OUTER JOIN ought to be used: Let's say I have a "Person" class that has a foreign key reference to a "Company" class. If I create a query that looks for all Persons with a "company.company_name" = "foo", I correctly get an inner join between user and company on user.company_id=company.id. But if I create a query that asks for "company.company_name"="foo" OR "user_name"="foo" I ought to get a left outer join. But I still get an inner join. Workaround: Use a report query I hope this info can be helpful. Regards, Scott Howlett -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
