Pedro Salgado wrote: <snip>
Sure, this is much cleaner. But my code is only one line ;-)
Yes, but if I make an additional util class I can get the same effect (1 line) and abstract from the JDO implementation ;)... Maybe one more private attribute for the pmf on usecase implementation classes...
you are right. Of course it makes sense to hide the actual JDO implementation from the user code.
Another question...
What are the limitations of this JDO plugin? Can I use it safely for makePersistent, deletePersistent and getObjectById and transaction management (these are the only methods I need)?
I don't know of any restriction wrt. the JDO programming model. The only thing that is problematic is the query mechanism: if a JDOQL query is processed, the JDORI load the complete extent (i.e. all instance of a class) and matches each object against the search criteria. This can be a performance killer for large tables.
What if I use directly the JDBC connection using PersistenceBroker? Can't I have the best of both worlds?
sure you can. But of course your app is than no longer purely JDO compliant...
I don't want object cache... At least for now... So I am currently using a mixed solution between OJB Persistence Broker and JDBC. This way I make/delete/getByPK persistent objects very easily (and have a simpler yet effective model) and have the performance I need with JDBC (I guess this implies that I can't have object cache).
depends on what you do exactly...
I started abstracting OJB so I could switch to JDO in the future but, I realized I was developing something that already existed :D... So now I am planning to move to OJB JDO plugin but I am having second thoughts whether I can use the same JDBC retrieval strategy (for PersistenceBroker it worked very well).
sure, that's possible.
With my statements I was referring to the *internals* of SUN's JDO RI. it provides a plugin mechanism that abstracts the backen storage. An the OjbStore is an incarnation of such a plugin.
So when I coded the OjbStore Plugin I had no options to do any kind of jdbc by passing or something. Simply because the RI never aks the Plugin to perform any kind of query, but simply asks: give me all instances.
The only solution would be to change parts of SUN's JDO RI which is not possible to us as it is closed source.
But you are talking about *external* user code. Of course you can do any kind of mixture of OJB Apis. You can use JDO, PB, ODMG and OTM in paralell and spice it with some JDBC calls. no problem!
You just have to take care with transaction boundaries.
cu, thomas
unfortunately the JDORI plugin mechanims does not provide any interface to delegate queries down to the persistence kernel. SO OJB can't do any optimizations here and must load all instances of the extent and reach them back to the JDORI layers. This is one of the main reasons why we want to write our own JDO implementation.
The good news in your case: getObjectById() is not affected by this problem and works very efficiently.
That is certainly good.
Thank you for your response,
Pedro Salgado
cheers, thomas
Thank you,
Pedro Salgado
--------------------------------------------------------------------- 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]
