Anthony,

I was wondering, why must have so many static methods in SSession, that
most of the time end up finding the current scon in threadlocal, instead
of returning a SSession instance on open(), and passing around the
pointer as needed ?

(I must admit I am not that comfortable with multi-threading issues, so
what I am saying might be stupid)

Wouldn't:

SSession ses = SSession.open(datasource);

ses.begin();
ses.attachDataSet(ds);
List<Record> res = ses.findOrcreate(...);
ses.flush();
SDataSet newDs = ses.detachDataSet();
ses.commit();

SSession.closeSession();

be better ? So the factory+threadLocal part of SSession would be clearly
identified (public static methods open() and closeSession()), every
other public method beeing instance methods. This would avoid having to
get the current session from threadLocal every now and then in the code,
and would make clear SSession really has two distinct purposes.

As I already said, I am not sure at all about what I'm stating, so your
opinion on this really matters :)

Franck



Le jeudi 03 juillet 2008 à 09:50 +0200, Franck Routier a écrit :
> Hi,
>
> ok, I really
> like
SSession.newSessionAndAssociateWithCurrentThreadAndOpenJdbcConnection(),
which really says what it does..... :)
>
> I agree with the fact that a dataset must be a whole transaction
> cache,
> and that a session can only operate on one dataset at a time
> (begin/commit). And a record is either detached (from any dataset) or
> bound to one datset only. This makes sense to me, and doing otherwise
> is
> too far from what we've done until now. Would be scary :)
>
> The point I have trouble with is attach / detach semantics. What do
> you
> think it should be ?
>
> - only detach datset / or detach one record ?
> - only attach dataset / attach one record ?
> - if you are in an ongoing transaction, attaching a dataset mean
> merging
> the dataset, no only moving pointer... (I think of the updateList in
> particular)
>
> What do you think ?
>
> Franck
>
> Le jeudi 03 juillet 2008 à 15:10 +1000, Anthony Berglas a écrit :
> > Hello Franck,
> >
> > You've been busy again.
> >
> > >I agree with everything you say here. Regarding naming, maybe we
> > should
> > >consider JPA terminology ? Then Session would be EntityManager.
> > >And session.open() would then be joinTransaction()...
> >
> > I'm not sure that joinTranction a good description for
> > SSession.open. Maybe
> >
> SSession.newSessionAndAssociateWithCurrentThreadAndOpenJdbcConnection
> > would be explicit. But that is a bit too long. I personally like
> > just .open.
> >
> > I see what you have been trying to do with SDataSet etc. Might I
> > suggest:-
> >
> > SDataSet moves to simpleorm.record. It has no SSession variable. It
> > does have transactionCache (maybe renamed to just records) and
> > updateList. It contains implementations of findOrCreate etc. that
> > query its transactionCache (which just returns pointers to records
> in
> > its transactionCache). I do not think that it needs to implement
> any
> > interfaces.
> >
> > SRecordFinder is renamed database.SDataSetJdbc and extends
> > SDataSet. It is a data set that has been extended by a database. It
> > implements findOrCreate etc. to query the database. It is not a
> > public class for now, only dispached to via SSession.
> >
> > SSession creates one new SDataSetJdbc instance in BeginTransaction,
> > which it nulls at commit/rollback. SSession.findOrCreate just
> > dispatches to SDataSetJdbc.
> > (Avoid creating garbage per simple query. There can be quite a lot
> > of them, and performance is not completely unimportant.)
> > SSession contains the ThreadLocal code. SSession and SDataSetJdbcr
> > are really just one class split into two for convenience.
> >
> > SQueryEngine and SManager are deleted. (Interfaces can always be
> > easily added back later if useful, otherwise they are clutter.)
> >
> > SDataSet.query(SQuery) can just throw a unimplemented exception for
> > now. But its @Override in SDataSetJdbc does the normal execute.
> >
> > Attaching an SDataSet to a SSession/SDataSetJdbc just moves
> pointers
> > to records over. An SRecordInstance can only ever belong to one
> > SDataSet at a time (many problems otherwise). So attach method
> > should be called something like
> > SSession/SDataSetJdbc.moveRecordsFrom(SDataSet ds), and should
> remove
> > them from ds.
> >
> > What do you think?
> >
> > (One alternative view is that an SDataSet should just be a
> > List<SRecordInstance>. And queries would return an SDataSet rather
> > than a List. But SDataSets contain many different types of
> > records. And we would have records occurring in multiple data sets
> > at the same time, very dangerous.)
> >
> > Anthony
> >
> > At 08:52 PM 2/07/2008, Franck Routier wrote:
> >
> > >Hello Anthony,
> > >
> > >I agree with everything you say here. Regarding naming, maybe we
> > should
> > >consider JPA terminology ? Then Session would be EntityManager.
> > >
> > >And session.open() would then be joinTransaction()...
> > >
> > >The advantage of EntityManager over Session is that it explicitely
> > >states what it does. And SDataSet would also be an EntityManager...
> > >
> > >So maybe SSession and SDataSet would both implement
> "EntityManager".
> > But
> > >I don't think we should go for JPA EntityManager stricto sensu, the
> > API
> > >is quite poor and we wouldn't want to depends on it and guarantee
> the
> > >contract.
> > >
> > >Do you agree with that ?
> > >
> > >So what I propose is to have a common interface for SSession and
> > >SDataSet, lets call it SManager.
> > >
> > >I'll try this, and you can review it tomorow and tell if you like
> > it...
> > >
> > >Have a good night :)
> > >
> > >Franck
> > >
> > >BTW, where are you located (Austalia ?) I am in Clermont-Ferrand
> > >(France) and my local timezone is CEST (Continental Europe).
> > >
> >
> > Dr Anthony Berglas, anthony@... Mobile: +61 4 4838 8874
> > Just because it is possible to push twigs along the ground with ones
> > nose
> > does not necessarily mean that is the best way to collect firewood.
> >
> >
> >
> >
> >
>
>
>
>
>