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.