From: Anton v. S. <an...@ap...> - 2002-05-29 06:45:09
|
> to force associated objects to be saved/deleted/updated along with the > parent object. This should save a lot of application code. Sounds great! > (b) would it be useful to support cascade="save", > cascade="delete", cascade > ="update" along with cascade="all", cascade="none"? > > I can't really see any great use to the extra stuff in (b). I can't think of *any* uses for that, but perhaps that's just my limited imagination. If you don't support the options, perhaps use cascade="true" or "false"? > In other news, I decided to deprecate Session.create(). Does anyone have > any objections to this? I ran across something that might have some relevance here: I implemented PersistentLifecycle in all of my classes, primarily to save a reference to the session in each object, since I find passing the session around between objects too intrusive. When you create an object using an ordinary constructor, though, it obviously can't automatically get a reference to the session, which leads to problems if the methods in that class expect to be able to access the session. So some mechanism is needed to set the session for objects created directly by constructor: passing the session to the constructor, or using a setSession() method, perhaps. I assume calling save() early on isn't practical, before initialization of the object is complete. I just mention this because I assume the issue it wouldn't arise with Session.create(). I haven't done enough actual application coding yet to know how much of an issue this will be in practice, though, and I haven't yet chosen a solution. Having the constructors accept a session may be OK. Please let me know if I'm missing a better way. Anton |