On 13/01/2004 14:34, "Thomas Mahler" <[EMAIL PROTECTED]> wrote:
> Hi pedro,
>
> Pedro Salgado wrote:
>> In tutorial 4 I found something like:
>>
>> factory = new OjbStorePMF();
>>
>>
>> Isn't this a better way to create a PersistenceManagerFactory?
>>
>> Properties props = new Properties();
>> props.setProperty("javax.jdo.PersistenceManagerFactoryClass",
>> "org.apache.ojb.jdori.sql.OjbStorePMF");
>>
>> PersistenceManagerFactory pmf =
>> JDOHelper.getPersistenceManagerFactory(props);
>> PersistenceManager pm = pmf.getPersistenceManager();
>>
> 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...
>
>> 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?
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).
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).
>
> 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]
