RE: Persister approach all wrong. Reverted to r591

Just wanted to tell you that all this is really interesting when it comes to
API design.
 
Where can I get the source ? Is this in a branch or on the main trunk ?
 
Also, I was carried away from SimpleORM and had extensive experience with
Hibernate but really do not like it much.
 
Frank, what would be the key differentiator that makes you tick when it
comes to SimpleORM ?
 
TIA
/Philippe Back

   _____  

From: [email protected] [mailto:[email protected]] On Behalf
Of Anthony Berglas
Sent: mardi 8 juillet 2008 3:45
To: Franck Routier
Cc: [email protected]
Subject: [SimpleORM] 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.doFindorCr-eate 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.findOrCrea-te
SDataSetJdbc.-findOrCreate/-SDataSet.-findOrCreate/-SDataSet.-doFindOrCreate
SDataSetJdbc.-findInDatabase
SSession.commit
dataSet = null

MINE WRONG -- r613
SDataSet.findOrCrea-te/doFindOrCreat-e
SPersister.findInDa-tabase
SDataSet.commit
records.clear

CORRECT
SSession.findOrCrea-te
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
((SPersisterDatabas-e)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, HYPERLINK
"mailto:anthony%40berglas.org"[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, HYPERLINK
"mailto:anthony%40berglas.org"[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.



 


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.6/1539 - Release Date: 7/07/2008
18:35



No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.11/1553 - Release Date: 15/07/2008
5:48