RE: Re: Record caching
[email protected] Wed, 01 Jul 2009 15:29:12 +1000
| Newsgroups | gmane.comp.java.orm.simpleorm |
|---|---|
| Message-ID | <[email protected]> |
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: [email protected] >From: [email protected] >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:[email protected]>[email protected] >>From: <mailto:[email protected]>[email protected] >>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:[email protected]><mailto:[email protected]>[email protected], 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, [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/