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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > >
