Re[2]: [jcr-mapping] PersistenceManager

[Costin Leau <co...@gmail.com>]

Hello Christophe,

> On 10/4/05, Costin Leau <co...@gmail.com> wrote:
>> Hello,
>>
>>  PersistenceManagerImplementation duplicates method from JCR session
>>  (item Exists and logout).
> How to check if an object exists ?
> There is 2 possibilities (IMPO) :
> * Check on the node path (/mypath/mynode)
> * Manage a unique id/object.
I'm not talking about how to check if an item exists but rather about
what this method does on the PersistenceManager interface. What value
does it adds - it's a duplicate of session, same signature but with a
different exception.
Why not remove the whole method ?; the code internally uses the session
anyways.

From PersistenceManager one would expect a method like
exists(Object, String) - a method that check that an object is mapped
correctly inside the repository.

> Currently, the framework is using the first one. Is it necessary to
> use unique ID in a content repo context. I think the path is a good
> candidate to check if the object exist or not. Anyway, I'm agree to
> support both and/or see other alternatives.

The check is made for the existence of an item not an object; there is no
mapping just code duplicate.

>>Moreover this class which handles
>>  persistence and should be Repository bound is actually session-bound
>>  (one per session).
>>  Shouldn't the manager be one per Repository instead of one per
>>  session?

> Maybe the interface name is not correct (PersistenceManager) but this
> class is bound to a session. How to retrieve, update, delete object
> (and its underlaying nodes/prop) without a session object ? Logout
> method seems to be also important if it is bound to a JCR session.
The manager can get sessions from the repository using the login()
method. Right now the interface handles not only the persistence but
also session management. One one hand it requies a session to be given
but it can logout/close the session - what's the use, again?
It's just another method exactly replicated from the session with a
different signature. How does it help the mapping?

>>  Moreover I've seen there is no method for deleting an object but
>>  rather for removing a node which forces the developer to handle the mapping
>>  of the object in the JCR; there is no conversion being done at
>>  deleting time.

> Same as exist : either we delete a object with a path or an ID.

The actual implementation as I see removes the whole tree - there is
no mapping. I should give an object for removal AND a path, not just a
path - I want the mapping of the object to be removed not the whole
tree otherwise I would do that manually on the session.


-- 
Best regards,
 Costin                            mailto:costin.leau@gmail.com

Fwd: Re[4]: [jcr-mapping] PersistenceManager

[Christophe Lombart <ch...@gmail.com>]

Ooops, By error, I reply only to Costin, here his reply in order to
continue our discussion on the Graffito mailing list. I will reply
ASAP.

Sorry
Christophe

On 10/4/05, Costin Leau <co...@gmail.com> wrote:
> Hello Christophe,
>
> >> From PersistenceManager one would expect a method like
> >> exists(Object, String) - a method that check that an object is mapped
> >> correctly inside the repository.
> >>
> > I think both methods are usefull :
> > exist(path)
> > exist(Object, path)
>
>
> >> The check is made for the existence of an item not an object; there is no
> >> mapping just code duplicate.
> >>
>
> > It is not really code duplicate, it is a way to redirect to the
> > internal session object.
> Considering that the session is actually used and there is no
> mapping/persistence involved I see no new functionality here.
>
> > The session object should be private. If the persisenteManager is
> > bound to a Session, this method seems to me usefull.
> Okay but then it should be private or protected not public AND on an
> interface. Why should the implementations be force to redirect this to
> the session?
>
> >> Right now the interface handles not only the persistence but
> >> also session management. One one hand it requies a session to be given
> >> but it can logout/close the session - what's the use, again?
> >> It's just another method exactly replicated from the session with a
> >> different signature. How does it help the mapping?
> >>
> > Again, for me, the persistenceManager is bound to a session. Following
> > the JCR session, you have some method to logout, check if a node
> > exist, ...
>
> > If you drop the logout method, how to log out  :-) ?
> As I've said, considering that the developer has to open a session in
> order to create the persistence manager it has a reference so he/she can
> manually logoff. Session management is not the persistence manager
> concern.
>
> >> The actual implementation as I see removes the whole tree - there is
> >> no mapping. I should give an object for removal AND a path, not just a
> >> path - I want the mapping of the object to be removed not the whole
> >> tree otherwise I would do that manually on the session.
> >>
>
> > Removing a subtree is an interesting process. I would like to
> > encapsulate some usefull JCR session methods because the
> > PersistenceManager is bound to one session.
> > Anyway, your suggestions are very good and I think we can add other
> > methods like :
> > * exist(object, path)
> > * remove(object, path)
>
> > If you think that we are not  on the same way, can you send me your
> > interface proposal. That will help me to understand your ideas in more
> > details. I'm wondering how you manage your session in a such
> > situation.
> You mentioned something about OJB or Hibernate in the proposal. Take a
> look at the Session interface (org.hibernate.Session) and trim it
> down.
> A simple interface would be:
> add(Object)
> remove(Object);
> update(Object);
> exists(Object);
>
> Note I did not mention any path as this can be already present in the
> XML mapping. If these basics are supported the path can be easily
> added later.
>
> What session management are you talking about? I'm surprised to see
> interfaces which have no mapping functionality but rather duplicate
> Session methods/signatures.
> Are you using the current mapping implementation per-se?
> Try to do an insert and remove - a simple UC.
> The current interface doesn't allow this and we are talking
> about basic operations not collection findings, proxies or caching.
> It's ... wierd to see discussion about 2nd level cache when basic
> INSERT/UPDATE/DELETE methods do not exist even as signatures.
>
> P.S. Why did you stop using the mailing list?
> --
> Best regards,
>  Costin                            mailto:costin.leau@gmail.com
>
>

Re: Re[2]: [jcr-mapping] PersistenceManager

[Christophe Lombart <ch...@gmail.com>]

On 10/4/05, Costin Leau <co...@gmail.com> wrote:
>
> Hello Christophe,
> > Ok ! Now I understand you :-). The current code was build to make a
> > prototype and discovering the JCR spec and now it is time to review all
> > thinks.
> > We have 2 possibitities :
> > * Use distinct components : PersistenceManager and a JCR session object.
> In
> > this case, we can forget all methods like exist, logout, ... in the
> > PersistenceManager
> > * Use only the PersistenceManager which encapsulate the JCR session. but
> in
> > this case, we have to build a component manager/factory or other thinks
> > which can initialise the PersistenceManager correctly.
>
> > Is is a good summary of our discussion ? What do you like solution 1 or
> 2 ?
> There are other possibilities:
> 1. The Persistence Manager is configured per Repository and can
> retrieve the session by itself.
> 2. It's a variation of the first solution. The Manager contains only
> persistence related methods but is still session-bound (it requires a
> session). PersistenceManager dependencies however are initialized by
> the manager itself - for example right now the developer has to take
> care of converters and query manager even though this is not his
> concern but actually the PersistenceManager; the internals have been
> externalized.



What do you think if the persistence manager dependencies are initialised
/injected by the Spring assembly script ?

>>You mentioned something about OJB or Hibernate in the proposal. Take a
> >>look at the Session interface (org.hibernate.Session) and trim it
> >>down.
> >>A simple interface would be:
> >>add(Object)
> >>remove(Object);
> >>update(Object);
> >>exists(Object);
> >>Note I did not mention any path as this can be already present in the
> >>XML mapping. If these basics are supported the path can be easily
> >>added later.
>
> > So, you force to have in each object, the attribute "path" - Correct ?
> It's just an idea to make a prototype at the beginning and then
> generalize, not the other way around. And yes, the mapping has to
> contain the path (the naming or if it's an attribute/property is not
> important).


Ok let do the prototype and we will see.

Re[2]: [jcr-mapping] PersistenceManager

[Costin Leau <co...@gmail.com>]

Hello Christophe,
> Ok ! Now I understand you :-). The current code was build to make a
> prototype and discovering the JCR spec and now it is time to review all
> thinks.
> We have 2 possibitities :
> * Use distinct components : PersistenceManager and a JCR session object. In
> this case, we can forget all methods like exist, logout, ... in the
> PersistenceManager
> * Use only the PersistenceManager which encapsulate the JCR session. but in
> this case, we have to build a component manager/factory or other thinks
> which can initialise the PersistenceManager correctly.

> Is is a good summary of our discussion ? What do you like solution 1 or 2 ?
There are other possibilities:
1. The Persistence Manager is configured per Repository and can
retrieve the session by itself.
2. It's a variation of the first solution. The Manager contains only
persistence related methods but is still session-bound (it requires a
session). PersistenceManager dependencies however are initialized by
the manager itself  - for example right now the developer has to take
care of converters and query manager even though this is not his
concern but actually the PersistenceManager; the internals have been
externalized.

>>You mentioned something about OJB or Hibernate in the proposal. Take a
>>look at the Session interface (org.hibernate.Session) and trim it
>>down.
>>A simple interface would be:
>>add(Object)
>>remove(Object);
>>update(Object);
>>exists(Object);
>>Note I did not mention any path as this can be already present in the
>>XML mapping. If these basics are supported the path can be easily
>>added later.

> So, you force to have in each object, the attribute "path" - Correct ?
It's just an idea to make a prototype at the beginning and then
generalize, not the other way around. And yes, the mapping has to
contain the path (the naming or if it's an attribute/property is not
important).

-- 
Best regards,
 Costin                            mailto:costin.leau@gmail.com

Re: [jcr-mapping] PersistenceManager

[Christophe Lombart <ch...@gmail.com>]

On 10/4/05, Costin Leau <co...@gmail.com> wrote:
>As I've said, considering that the developer has to open a session in
>order to create the persistence manager it has a reference so he/she can
>manually logoff. Session management is not the persistence manager
>concern.

Ok ! Now I understand you :-). The current code was build to make a
prototype and discovering the JCR spec and now it is time to review all
thinks.
We have 2 possibitities :
* Use distinct components : PersistenceManager and a JCR session object. In
this case, we can forget all methods like exist, logout, ... in the
PersistenceManager
* Use only the PersistenceManager which encapsulate the JCR session. but in
this case, we have to build a component manager/factory or other thinks
which can initialise the PersistenceManager correctly.

Is is a good summary of our discussion ? What do you like solution 1 or 2 ?

>You mentioned something about OJB or Hibernate in the proposal. Take a
>look at the Session interface (org.hibernate.Session) and trim it
>down.
>A simple interface would be:
>add(Object)
>remove(Object);
>update(Object);
>exists(Object);
>Note I did not mention any path as this can be already present in the
>XML mapping. If these basics are supported the path can be easily
>added later.

So, you force to have in each object, the attribute "path" - Correct ?


>Try to do an insert and remove - a simple UC.
>The current interface doesn't allow this and we are talking
>about basic operations not collection findings, proxies or caching.
>It's ... wierd to see discussion about 2nd level cache when basic
>INSERT/UPDATE/DELETE methods do not exist even as signatures.

Yep, some refactoring is needed there. Again, the code was used to build a
prootype and now it is time to review all think.


Christophe