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



Le mercredi 02 juillet 2008 à 20:18 +1000, Anthony Berglas a écrit :
> Hello Franck,
>
> Wow, you have been busy.
>
> I agree that we need to be careful about our
> vocabulary, I had been a bit
> sloppy. SCon."attach/detach" had referred to
> both the attachment of an SCon to a Thread, and
> also the attachment of an SRecordInstance or
> SDataSource to a SCon. The latter is the meaning for Hiberbate.
>
> I would also like to rename SCon to
> SSession. This is the term Hibernate uses. I
> think it will help adoption if we try to use
> Hibernate terminology where it is appropriate.
>
> So I am inclined to reserve attach/detach for records and data sets of
records.
>
> You have introduced "bind". But then the
> opposite is still detachAndClose. I am thinking
> that these should simply be SSesson.open()
> (instead of bind) and SSesiion.close().
>
>
> > > shouldn't "myDS.create(new Employee().set(Employee.ID,
> > > "123").set.....);" rather be called :
> > > myDS.attach(new Employee().set(Employee.ID, "123").set.....);
>
> Yes. should be
> myDS.attach(new Employee().set(Employee.ID, "123").set.....);
> or, what I meant to say
> myDS.create(Employee.meta, "123").set...
>
> I am thinking that all the SSession.findOrCreate
> style methods should also be available in
> SSataSet. Later SSession.findOrCreate might just
> be defined as a short cut to
> SSession.getDataSet().findOrCreate etc. Or maybe
> a common interface. But the static SSession.findOrCreate are be convenient.
>
> The Simpleorm.database package should be renamed
> simpleorm.session. The reason is that we might
> later want to split out a simpleorm.database that
> had all the drivers, and was called by a now very
> small SSession class. Sorry for getting this wrong earlier.
>
> [I do not want to do any renaming work that would break your application.]
>
>
> SFieldReference also needs work. I am thinking
> SRecordInstance.getRawReference gets the raw
> reference without ever doing a lazy fetch. Then
>
> Department dep = SSession.getReference(myEmp.DEPARTMENT);
>
> Retrieves from the database if and only if
> necessary. I think that this means that we can
> get rid of getReferenceWhileDetached -- the user
> can just do it. (SRecordInstance.IsNull would
> indicate whether the scalar key fields are null,
> vs getRawReference==null might just indicate that
> it might not have been fetched yet.)
>
>
> I strongly suggest that we do not go past step 7
> until the build is split and everything is reasonably clean.
>
> It is late here. Tomorrow I want to start on
> revising the white paper. It would be good if
> you can get the renaming done today.
>
> Regards,
>
> Anthony
>
>
>
>
> At 05:59 AM 2/07/2008, Franck Routier wrote:
>
> >Anthony,
> >
> >I've done some work, namely steps 1 to 6, execpt for the 'flush before
> >query part'.
> >Lot of thinks are now public, including some fields. Bad.
> >
> >Also SRecordMeta select methods should be moved to SDriver (or
> >SRecordFinder ?).
> >
> >etc.
> >
> >Franck
> >
> >Le mardi 01 juillet 2008 à 16:46 +0200, Franck Routier a écrit :
> > > Hi Anthony,
> > >
> > > that seems fine to me, except for one point that is not that clear :)
> > >
> > > shouldn't "myDS.create(new Employee().set(Employee.ID,
> > > "123").set.....);" rather be called :
> > >
> > > myDS.attach(new Employee().set(Employee.ID, "123").set.....);
> > >
> > > Also, one should probably be able to attach a single record to SCon,
> > > without first having a SDataSet (or one must have a convinient way to
> > > create an empty SDataSet).
> > >
> > > So either :
> > >
> > > SCon.attach(new Employee().set(...));
> > >
> > > or
> > >
> > > SDataSet ds = new SDataSet(); // detached
> > > ds.attach(new Employee().set(...));
> > > SCon.begin();
> > > SCon.attach(ds);
> > >
> > > or both.
> > >
> > > We should probably also find another name for SCon.attach(DataSource).
> > > This is confusing. I propose SCon.bind(DataSource).
> > >
> > > That said, your action plan is alright. I am busy but will definitely
> > > find some time. The hard part is SDataSet query engine !! This is
> > > where
> > > we have to be clever (maintaining some kind of graph of relationships
> > > between records...)
> > >
> > > So let go on... I think we should agree on who does what in what
> > > order.
> > > I could tackle with the easy part (1. 2. and 3.) to begin. Do you
> > > agree
> > > on that ?
> > >
>
> 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.