> 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
|
