Hi!
Just 2 comments:
1/ we can revisit this thread at any moment
2/
> 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). I
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 ;-).
./alex
--
.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)
Hibernate.initialize(collection)).
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; this
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
