incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <>
Subject Re: JCR mapping package naming
Date Fri, 10 Feb 2006 10:13:35 GMT

Just 2 comments:

1/ we can revisit this thread at any moment

 > void retrieveReference(java.lang.Object obj,
 >                        java.lang.String attrName)
 >                        throws PersistenceBrokerException

That is exactly what I was reffering too. Now the question is: do the attrName works only
on the 1st 
level of properties or is it a deep attribute name (something as: myUser.address.street.number).
am afraid of this 2nd approach cause than it will need an OGNL like property parser.

However, I agree to put this thread on hold and go back to inheritance. I really think you
will like 
what I will come out with ;-).

.w( the_mindstorm )p.

#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/10/2006
11:34 AM) :#
> Alex,
> Honnestly, I'm not yet thinking about all implementation details for
> the lazy loading.
> Following our common plan, I want to speak in the first time on the
> inheritance & interface support (in the other ml thread).
> I would like to review the OJB implementation for the lazy loading
> (which works fine) before taking a technical decision.
> ... but here some comments :
>>you do that? I see 3 possible approaches:
>>- create a new Session for each lazy-loaded field?
>>- place a Session on some ThreadLocal?
>>- bind to each object that has lazy-loaded object the javax.jcr.Session.
>>I find all these really problematic and limitative. Do you have in
> mind other approach?
> Right now, I don't see another approach - it should be somehting around that.
> We have to find a way to reuse the same session for the atributes to
> "lazy" load. Yes, there are some limitations (eg. it is not possible
> to close the PM after retrieving the main object). OJB uses a pool of
> PM and of course a pool of db connection. This solution seems to limit
> the number of session to use. I'm will review it.
> Again I'm more focusing on the inheritance. We need more time to think
> about that. Can we go back on this issue after solving the inheritance
> and interface issues ? I'm reviewing all possibilities in OJB because
> I forget some details. OJB offers byte code manipulation whith CGLIB
> and another one with java proxy. I'm wondering if we can reuse some
> code there.
>>I would probably like more something in the auto-retrieval direction:
> pass to the >PersistenceManager
>>you object, the property access path and than handle this part inside
>>PersistenceManager (I guess
>>Hibernate has something in this direction with Hibernate.initialize(object)
> OJB provides a nice methods (sorry I like this tools :-) ) :
> void retrieveReference(java.lang.Object obj,
>                        java.lang.String attrName)
>                        throws PersistenceBrokerException
>     Retrieve the specified reference or collection attribute for the
> given persistent object.
> void retrieveAllReferences(java.lang.Object obj)
>                            throws PersistenceBrokerException
>     Retrieve all references and collections of the given persistent object
>   I think it is better to use the object + attributes reference
> instead of xpath exp.
>> I think I need some more clarifications about the meaning/behavior of auto-update.
>> Considering that an object ObjectA has a property propertyInA described as auto-update=false;
>> property was modified after fetching it from the repository, now ObjectA is passed
to update. What
>> is happening to propertyInA? Is it ignored even if it was modified?
>> Same question for some collectionInA, where a property of an object in collection
was modified.
> My proposal is to ignore this modification. In some conditions , the
> auto-retrieve and auto-update can be very dangerous but can increase
> the performances.
> --
> Best regards,
> Christophe

View raw message