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.