Re: The Big Split -- SimpleOrm.records and SimpleOrm.database.

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, [email protected]       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.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/