incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Fwd: Re[4]: [jcr-mapping] PersistenceManager
Date Tue, 04 Oct 2005 10:40:44 GMT
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 <costin.leau@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
>
>

Mime
View raw message