Search the web
Sign In
New User? Sign Up
SimpleORM
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
The Big Split -- SimpleOrm.records and SimpleOrm.database.   Message List  
Reply | Forward Message #1555 of 1851 |
Re: [SimpleORM] 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, 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.




Wed Jul 2, 2008 10:18 am

aberglas
Offline Offline
Send Email Send Email

Forward
Message #1555 of 1851 |
Expand Messages Author Sort by Date

Hello Franck, I think that as part of 3.0 we should consider splitting SimpleOrm into two pieces, each in their own Jars. simpleorm.records that contains...
Anthony Berglas
aberglas
Offline Send Email
Jun 30, 2008
5:57 am

Hello Frank, Moving SQuery out is possible. One would have to store the built query as a structure rather than a query string, and then translate to string in...
Anthony & Melissa Ber...
berglas@...
Send Email
Jun 30, 2008
10:45 am

Anthony, maybe we should consider introducing SDataSet (or SDataSetManager ?) right now. First it would be equivalent to SConnection's transaction cache and ...
Franck Routier
routier_franck
Offline Send Email
Jun 30, 2008
2:24 pm

Hello Franck, Hmm. The design gets ever more ambitious. I am concerned that if we take on too much we will not finish. But it would be good to get this...
Anthony Berglas
aberglas
Offline Send Email
Jul 1, 2008
11:18 am

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.....);"...
Franck Routier
routier_franck
Offline Send Email
Jul 1, 2008
2:46 pm

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...
Franck Routier
routier_franck
Offline Send Email
Jul 1, 2008
7:59 pm

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 ...
Anthony Berglas
aberglas
Offline Send Email
Jul 2, 2008
10:18 am

Hello Anthony, I agree with everything you say here. Regarding naming, maybe we should consider JPA terminology ? Then Session would be EntityManager. And...
Franck Routier
routier_franck
Offline Send Email
Jul 2, 2008
10:52 am

Hello Franck, You've been busy again. ... I'm not sure that joinTranction a good description for SSession.open. Maybe ...
Anthony Berglas
aberglas
Offline Send Email
Jul 3, 2008
5:11 am

Hi, ok, I really like SSession.newSessionAndAssociateWithCurrentThreadAndOpenJdbcConnection(), which really says what it does..... :) I agree with the fact...
Franck Routier
routier_franck
Offline Send Email
Jul 3, 2008
7:50 am

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...
Franck Routier
routier_franck
Offline Send Email
Jul 3, 2008
12:35 pm

Hmm. The motivations for attaching the session to a thread local were:- 1. It avoids having to pass a connection variable everywhere. In a database...
Anthony Berglas
aberglas
Offline Send Email
Jul 4, 2008
2:11 am

Hello Franck To keep it simple, the semantics of attaching a data set to a session could be exactly the same as attaching each record in it, one by one. As ...
Anthony Berglas
aberglas
Offline Send Email
Jul 4, 2008
12:47 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help