Hello Garry,

I am confused by your use case.

If you just want to have a record set of cached values that is not really part
of the transaction, then just don't attach it. You can query the detached
SDataSet directly with SDataSet methods. This will work for codes etc.

If you want to update two or more Data Sets in different transactions, you will
have to manage the sessions manually. But that is a really strange use case.

If you want a generic, fully automatic caching mechanism, then that is not
SimpleOrm. It is not really Hibernate either unless you are extremely careful.
Generally a very bad idea unless you have proven performance requirements.
Leads to horrible bugs.

The attach method has been removed, so please do not depend on it.

One way or the other you will need to know when to start your transactions.
There is usually an obvious place at the outer level, eg. where the servlet is
called.

Regards,

Anthony

At 11:39 PM 30/06/2009, you wrote:
>Hi,
>
>(Before we get into this I just wanted to say that I really like simpleORM and
it has helped me enormously. I dont want to come off like I am complaining
about something, because I am not and have no right to. I am just trying to
understand your product and its proper use. And maybe my comments/issues will
even help.)
>
>I am aware of session.hasBegun and I use it in various places. However, it
will not help in this situation.
>
>The implied assumption in attaching a dataset with a session.begin(DS) is you
know that you are at the beginning of something. If classes are being called in
some arbitrary order, a class will not be guaranteed to be at the start of a
session. Therefore, if it has a dataset (or records) it wants to add to the
active dataset it cannot do so if the session has already begun and will be
stuck out of luck.
>
>This is a small (and maybe contrived) limitation, but i have actually run into
it. It is not hard to see how this can come up if a person is getting records
from free form queries or using stored procedures and then wants to add all or
some of those records to the active dataset.
>
>I have gotten around this issue by using the deprecated attach method. I did
not want to do it, but I dont think I had any other choice. This is one of the
reasons I started this thread. It seems to me that while the attach method is
not for "normal" use, removing it from SimpleORM will reduce it flexibility.
>
>Again, thanks for SimleORM
>GA
>
>
>
>----------
>
>To: SimpleORM@yahoogroups.com
>From: berglas@...
>Date: Wed, 24 Jun 2009 18:35:04 +1000
>Subject: RE: [SimpleORM] Re: Record caching
>
>
>
>
>Normally you start your sessions at the top level where a request comes in.
>
>But you can call session.hasBegun() to find out.
>
>Anthony
>
>At 12:27 AM 9/06/2009, you wrote:
>
>>Thanks for the response.
>>
>>I looked thru LongTransactionTest. From what I see, it looks like the code
assumes it can set the dataset for a session. I dont know the order in which my
classes will be called. And if they are doing lazy loading of data, I always run
the risk that session.begin() has already been called by some other class in
this thread and therefore the class will get an exception by calling
ses.begin(ds).
>>
>>GA
>>
>>
>>
>>----------
>>
>>To: <mailto:SimpleORM@yahoogroups.com>SimpleORM@yahoogroups.com
>>From:
<mailto:berglas@...>berglas@...
>>Date: Mon, 8 Jun 2009 10:11:33 +1000
>>Subject: Re: [SimpleORM] Re: Record caching
>>
>>
>>
>>
>>
>>Hello Gary
>>
>>You could also just reattach the data set to a session (ses.begin(ds)) updated
it, then detachAndCommit again. See LongTransactionTest.simpleDetachTest.
>>
>>But yes, only one data set at a time per session. Hard to see how that would
be a problem, but bad things could happen otherwise. (You could trick SimpleORM
into having two sessions for the same JDBC connection, but that would probably
be a very bad idea.)
>>
>>As noted previously on this list, the single record detaching from Sessions
has been completely removed from the Subversion version. Now records must always
live in a DataSet. The SDataSet.attach method that you were using is for
internal use only.
>>
>>Anthony
>>
>>At 04:24 AM 8/06/2009, you wrote:
>>
>>>--- In
<mailto:SimpleORM%40yahoogroups.com><mailto:SimpleORM@yahoogroups.com><mailto:Si\
mpleORM@yahoogroups.com>SimpleORM@yahoogroups.com, gary adams <gershonadams@...>
wrote:
>>>>
>>>>
>>>> I have been using SimpleORM for the last two months and its a great tool. I
have a question about record caching
>>>>
>>>>
>>>>
>>>> If one has static information in the database that he wants to cache in an
application, like configuration information, what is the proper methodology of
doing this with simpleORM? The app will need access to this information
throughout its life.
>>>>
>>>>
>>>>
>>>> I have done it likes this.
>>>>
>>>>
>>>> LIST<x> listX= session.queryNoFlush(queryDEF);
>>>> session.commitAndDetachDataSet();
>>>>
>>>> Is this correct? I am concerned that the commit being done in the class
that requires the cache will affect other items in the database that should not
be committed yet.
>>>>
>>>
>>>You can make this action as first one after starting your program. So no
other items in the database can be affected, because your program hasn't any
open transactions yet.
>>>
>>>> Along the same lines, what is the proper way to attaching records to a
dataset from a rawquery? I have used
>>>> session.getDataSet().attach(record), but I am concerned because it is
deprecated.
>>>
>>>You can use something like:
>>>
>>>SRecordMeta<? extends SRecordInstance> metaRec;
>>>SRecordInstance record = dataSet.createWithNullKey( metaRec );
>>>
>>>Then you fill the record with functions like:
>>>
>>>record.setString( f, value );
>>>
>>>Good luck
>>>Thomas
>>>
>>>
>>

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.