Re: Session Objects Approach
On 10/16/07, Ayodeji Aladejebi <[EMAIL PROTECTED]> wrote: > thanks eelco i get your point. deciding what to sacrifice in design whether > memory or cpu/db traffic is always some challenge for most developers but if > I dont want my DB crying then its probably time to buy more RAM To sum up the whole detachable vs non-detachable models discussion: sometimes detachable works better and sometimes not - just decide on a case by case basis :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
On 10/16/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > I think what you all are missing in this discussion is that ldms are > mostly uss for read only data, not for forms. I still don't agree with that. :-) I use ldms in forms myself all the time. The big catch is that you have to persist changes right away or you'll loose them. But - save for when you do 'multi step' things, this is often what you do anyway. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
On 10/16/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > Well, detachable models are mostly used for something you can > relatively easily reconstruct. If you are building a complex object > (multi-step wizard etc.) then you don't what to use a detachable > object for it. Agreed. Wizards are a good example of where you non-detachable object often work better. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
> I found another con with detachable is that if you are constructing a complex > object graph _before_ putting it in the database you would have to do > something cleverer... e.g. only detach if already persisted? We just stuck > with non-detachable models. But the solution to that might be easy: only use the detachable model on the top object of your complex graph, and let all other models use that model (opposed to the model object). Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Just trying to be helpful. :-) Igor Vaynberg wrote: I think what you all are missing in this discussion is that ldms are mostly uss for read only data, not for forms. -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
I think what you all are missing in this discussion is that ldms are mostly uss for read only data, not for forms. -igor On 10/16/07, Matt Jensen <[EMAIL PROTECTED]> wrote: > > Another potential gotcha with detachable models is that they can make > versioning/optimistic locking a bit more difficult to use. Unless you > cache the base version of your entity in the detachable model and do > your own version checking, the typical implementations that I have seen > will happily reload and overwrite whatever version happens to be in the > database at the time of a request. This means, for example, that the > user might see a form that is initialized with version 1 of your object, > and then update version 2 if somebody else comes along and makes changes > before they submit, potentially wiping out the other user's changes. > > Obviously, this only affects you if you are versioning your objects. > It's just a nice tidbit to have in the knowledge base...and again, you > can design your detachable models around it. You just end up with a > little duplication of effort, as Hibernate/JPA/etc. already does this > for you elsewhere. > > > Ayodeji Aladejebi wrote: > > thanks eelco i get your point. deciding what to sacrifice in design whether > > memory or cpu/db traffic is always some challenge for most developers but if > > I dont want my DB crying then its probably time to buy more RAM > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Another potential gotcha with detachable models is that they can make versioning/optimistic locking a bit more difficult to use. Unless you cache the base version of your entity in the detachable model and do your own version checking, the typical implementations that I have seen will happily reload and overwrite whatever version happens to be in the database at the time of a request. This means, for example, that the user might see a form that is initialized with version 1 of your object, and then update version 2 if somebody else comes along and makes changes before they submit, potentially wiping out the other user's changes. Obviously, this only affects you if you are versioning your objects. It's just a nice tidbit to have in the knowledge base...and again, you can design your detachable models around it. You just end up with a little duplication of effort, as Hibernate/JPA/etc. already does this for you elsewhere. Ayodeji Aladejebi wrote: thanks eelco i get your point. deciding what to sacrifice in design whether memory or cpu/db traffic is always some challenge for most developers but if I dont want my DB crying then its probably time to buy more RAM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Well, detachable models are mostly used for something you can relatively easily reconstruct. If you are building a complex object (multi-step wizard etc.) then you don't what to use a detachable object for it. -Matej On 10/16/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > I found another con with detachable is that if you are constructing a complex > object graph _before_ putting it in the database you would have to do > something cleverer... e.g. only detach if already persisted? We just stuck > with non-detachable models. > > > > Eelco Hillenius wrote: > > > >> Does this approach have any significant improvement over the former? and > >> what could be the cons > > > > Like Alex said, look at LoadableDetachableModel for instance. You > > don't have to discard right away; just do at at the end of the > > request. It's what detachable is for. > > > > Pro detaching: less memory consumption per session, and you can avoid > > lazy loading problems when you use e.g. Hibernate. Con: more database > > traffic (if you don't cache these objects) and cpu usage (though very > > very minimal). In general a pro is also that your objects are always > > fresh. A general con when working in forms can be that you have to > > persist changes right away or you'll lose them with the reload. > > > > Eelco > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > View this message in context: > http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
I found another con with detachable is that if you are constructing a complex object graph _before_ putting it in the database you would have to do something cleverer... e.g. only detach if already persisted? We just stuck with non-detachable models. Eelco Hillenius wrote: > >> Does this approach have any significant improvement over the former? and >> what could be the cons > > Like Alex said, look at LoadableDetachableModel for instance. You > don't have to discard right away; just do at at the end of the > request. It's what detachable is for. > > Pro detaching: less memory consumption per session, and you can avoid > lazy loading problems when you use e.g. Hibernate. Con: more database > traffic (if you don't cache these objects) and cpu usage (though very > very minimal). In general a pro is also that your objects are always > fresh. A general con when working in forms can be that you have to > persist changes right away or you'll lose them with the reload. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13229389 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
thanks eelco i get your point. deciding what to sacrifice in design whether memory or cpu/db traffic is always some challenge for most developers but if I dont want my DB crying then its probably time to buy more RAM On 10/16/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > Does this approach have any significant improvement over the former? and > > what could be the cons > > Like Alex said, look at LoadableDetachableModel for instance. You > don't have to discard right away; just do at at the end of the > request. It's what detachable is for. > > Pro detaching: less memory consumption per session, and you can avoid > lazy loading problems when you use e.g. Hibernate. Con: more database > traffic (if you don't cache these objects) and cpu usage (though very > very minimal). In general a pro is also that your objects are always > fresh. A general con when working in forms can be that you have to > persist changes right away or you'll lose them with the reload. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Session Objects Approach
> Does this approach have any significant improvement over the former? and > what could be the cons Like Alex said, look at LoadableDetachableModel for instance. You don't have to discard right away; just do at at the end of the request. It's what detachable is for. Pro detaching: less memory consumption per session, and you can avoid lazy loading problems when you use e.g. Hibernate. Con: more database traffic (if you don't cache these objects) and cpu usage (though very very minimal). In general a pro is also that your objects are always fresh. A general con when working in forms can be that you have to persist changes right away or you'll lose them with the reload. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Objects Approach
Take a look on LoadableDetachableModel.. Ayodeji Aladejebi wrote: > > Basically there is an object like this, a common model > > class User{ > Long id; > String username; > String password; > String fullname; > ... > List collections; > } > > From most examples and basic approach, i see references to this Object in > the session > During user sign in, this object is loaded from database and stored in the > memory and then during authentication, this object is checked against Null > to know if a user is signed in or not and then if required, a getter in > the > session returns the reference. > > > Please correct me if I am wrong, > > Now I thought, > > Instead of keeping the object reference in the session after a sign in, > why > not just keep the ID (Long) and then during authentication, the code just > checks for Null or Zero > and then if the entire user object is required in any of the pages, The > USER ID is passed into the DAO which then loads the object and then > discarded immediately after use so that no references exists to it again > > > Does this approach have any significant improvement over the former? and > what could be the cons > > Thanks > > -- View this message in context: http://www.nabble.com/Session-Objects-Approach-tf4600804.html#a13143236 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session Objects Approach
Basically there is an object like this, a common model class User{ Long id; String username; String password; String fullname; ... List collections; } >From most examples and basic approach, i see references to this Object in the session During user sign in, this object is loaded from database and stored in the memory and then during authentication, this object is checked against Null to know if a user is signed in or not and then if required, a getter in the session returns the reference. Please correct me if I am wrong, Now I thought, Instead of keeping the object reference in the session after a sign in, why not just keep the ID (Long) and then during authentication, the code just checks for Null or Zero and then if the entire user object is required in any of the pages, The USER ID is passed into the DAO which then loads the object and then discarded immediately after use so that no references exists to it again Does this approach have any significant improvement over the former? and what could be the cons Thanks