Persister approach all wrong. Reverted to r591

Hello Frank,

I'm glad you did not touch anything.  I think 
that I got it wrong.  I think that both the 
Persister and SDataSetJdbc are too complex.  The 
more I worked on this the messier it seemed to 
get.  So I will roll back two days work to your r591.

I think that the simple way is that SSession 
handles all the database interactions as 
before.  It is the main interface called by the user.

SDataSet is a thin layer that simply holds the 
list of records.  It has a simple find and a 
simple create but knows nothing of any 
persister.  It knows about which records are 
dirty, which columns are not valid, but nothing 
about transactions.  For now the only general 
query is to get all the records in one big collection .

So SSession.doFindorCreate first does a simple 
find on the SDataSet, then findInDatabase, then 
SDataSet.add.  SDatabase is just a one to one 
class with SSession to modularize the code.

Realistically, if ever there was a non jdbc 
persister, it would do something like XML, and so 
not have transactions etc. anyway.  So having a 
different SXmlSession that does not extend 
SSession but can also work on SDataSets is much 
cleaner than trying to coerce SSession to handle XML via a wierd persister.

This was pretty much my original idea, and where 
you had coded to.  But I lost the plot along the 
way.  SPersister always felt too complex.  Always 
avoid indirection, prefer simple, direct coding.

To Summarize:-

YOURS -- r591
   SSession.findOrCreate
      SDataSetJdbc.findOrCreate/SDataSet.findOrCreate/SDataSet.doFindOrCreate
         SDataSetJdbc.findInDatabase
   SSession.commit
      dataSet = null

MINE WRONG -- r613
   SDataSet.findOrCreate/doFindOrCreate
     SPersister.findInDatabase
   SDataSet.commit
      records.clear

CORRECT
   SSession.findOrCreate
     dataSet.find
     findInDatabase
     dataSet.add
   SDataSet.commit
     dataSet = null

== BEFORE SUNDAY'S CHANGES r591 ==

SDataSet
   HashMap records
   .findOrCreate...

SDataSetJdbc
   .findInDb

SSession
   .begin()
      dataSet = new SDataSetJdbc
   .commit()
      dataSet = null
   .detatchDataSet()
      SDataSetJdbc.detachDataSet
          ds=new DataSet
         forall records ds.attach
           return ds
    .findOrCreate delegates to SDataSet.

== MINE WRONG -- r613 ==

SDataSetTemp
   HashMap records
   .findOrCreate...

SPersister -- essentially abstract

SPersisterDatabase
   .findInDb
   .rawUpdateDb

SDataSetSession
   dataSetTemp
   persister

   .innerOpen
      new PersisterDB

   .begin()
      dataSet = new SDataSetTemp
   .commit()
      dataSet = null
   .detatchDataSet()
      SPersisterDatabase.detachDataSet
          ds=new DataSet
         forall records ds.attach
           return ds

    .findOrCreate delegates to SDataSet.  (to be removed)
    .db returns (SPersisterDatabase)persister

== TODO ==

The life time of SDataSetTemp is wrong, created 
at each transaction.  Needs to be longer lasting, 
and destroyed by default.  Cannot unify until lifetimes the same.

detachDataSet() just returns this, having closed()? persister.

SDataSession.db() is handy for
   mysession.db().rawUpdateDb(...) etc.
But cannot refer to SPersisterDatabase from dataset only Jar.  So need
   ((SPersisterDatabase)mysession.persister()).rawUpdateDb(...)
Messier, but a result of not subtyping DataSet.

Move ThreadLocal processing to new class.

Lots more code needs to be moved into the persister.

Transients need care.

At 11:44 PM 7/07/2008, Franck Routier wrote:
>Hello Anthony,
>
>I didn't touch anything in case you are still working on merging. Tell
>me when I must go on with the work.
>
>Franck
>
>
>Le lundi 07 juillet 2008 à 20:44 +1000, Anthony Berglas a écrit :
> > Hello Franck,
> >
> > It is almost ready for the merge of SDataSetSession with
> > SDataSetTemp.  I'd like to make this a priority because it is deeply
> > structural.
> >
> > The delegating methods first need to be made totally clean, such as
> > findOrCreate is now.  There are quite a few, such as dirtyPurge, that
> > are not.  And I am not sure that they are all useful.
> >
> > Need to keep the detached semantics simple.  There is no
> > begin/flush/commit when detached (otherwise you would need to
> > implement rollback -- bad idea).   When you attach a data set to a
> > database and commit all dirty records are automatically flushed, no
> > need to mark them as flushed (otherwise you have to deal with dirty,
> > unflushable records,  bad idea too).  It feels to me like there are
> > far too many flags.
> >
> > The end is in sight.  But after this no more restructures!!!
> >
> > Anthony
> >
> > 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.

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/