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

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, [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/