Fwd: Re: SimpleORM Download Form

>Date: Fri, 24 Oct 2008 18:01:32 +1000
>To: [email protected]
>From: Anthony & Melissa Berglas <[email protected]>
>Subject: Re: SimpleORM Download Form
>
>Hello Carl,
>
>You could just subtype SSessionJDBC and @Override commit.  However, 
>you might be better working directly with the methods in SDataSet.
>
>Realize that you can never keep multiple databases in "Lock Step", 
>unless they are master slave.  Forget what you read about two phase 
>commit, it cannot be done.
>
>And why are you doing it?  If it is for reliability then you should 
>use master/slave, such as Oracle DataGuard.  If it is for 
>performance then the lock stepping will slow you down more than just 
>having one database.
>
>Multiple database causes all sorts of problems (irrespective of 
>SimpleOrm).  I strongly suggest that you try to implement a single 
>database solution.
>
>Mapping Students to Subjects (say) you just explicitly create the 
>Enrollment table.  You will almost always want that anyway to store 
>Grades (say).
>
>Anthony
>
>At 03:28 AM 23/10/2008, you wrote:
>
>>Anthony,
>>
>>Yes, I see what you're saying. Getters/setters make working with 
>>certain things (Wicket's PropertyModels, for example) easier, but I 
>>could always write my own wicket models that would probably be more 
>>powerful anyhow with all of the extra meta-data that the SimpleORM 
>>framework lets me embed.
>>
>>I'm starting to think that my 2-week search for the right ORM 
>>framework might be over. Incidentally, you might be amused to know 
>>that my search started when I received my 840 (!!) page book on 
>>hibernate in the mail and then noticed the dozen or so extra jar 
>>files I needed just get get it to fire up...
>>
>>Perhaps you could clear up one thing for me:
>>
>>Is it true that the following would work? Our product uses JGroups 
>>to cluster nodes to one another. Each has its own copy of the 
>>database, which are kept synchronized in lockstep. Could I create a 
>>facade around SSessionJdbc that captured the call to "commit", and 
>>actually detached the DataSet, serialized it, broadcast it to all 
>>nodes (including the local node), and then re-attached it to a new 
>>transaction and committed it?
>>
>>Also, the whitepaper briefly mentions having to create the mapping 
>>entity for many-to-many relationships. Are there any examples of 
>>what this looks like available?
>>
>>Thanks,
>>Carl Gould
>>Inductive Automation
>>[email protected]
>>1.800.266.7798
>>
>>On Tue Oct 21 15:40:43 PDT 2008, Anthony Berglas wrote:
>>Hello Carl, There is no actual need to write get/setters, and in 
>>fact it is not often done. Just myEmp.get(NAME) vs myEmp.getNAME(). 
>>And for clustering it becomes easy to write generic code like 
>>myTable.get(myField). If you do feel the need to write get/set 
>>methods then the code required is exactly the same as for beans and 
>>pseudo POJOs. Without get/setters then the static fields is much 
>>*less* verbose than annotations (and certainly XML). Non-db Uses do 
>>not have to be aware of the SSessionJDBC persistence module and 
>>jar. They do have to be vaguely aware of the SDataSet interface, 
>>but it is about collections of data rather than persistence. 
>>Anthony At 02:34 AM 22/10/2008, you wrote: >name: Carl 
>>Gould > >goodpart: Tight integration with how the data is 
>>stored >(accessibility to IDs) can help with web design (links 
>>need >IDs).Entities are not byte-enhanced or dynamic proxies - I 
>>need this >because I need the record instances to be serializable 
>>for >clustering.Clean detachment model will work well for me 
>>re: >clustering (I think). > >concerns: Having to define static 
>>field metadata as well as >getters/setters seems a bit more verbose 
>>that an annotation-based >approach.Lack of transparency means that 
>>all developers need to >understand the persistence 
>>layer. > >organisation: Inductive Automation > >city: 
>>California > >orgdesc: Industrial automation design software - 
>>FactoryPMI > >nrprogrammers: 4 > >howknown: 
>>http://java-source.net/open-source/persistence > >comments: Well 
>>written documentation. It is only missing a list of >supported 
>>RDBMS, and a more in-depth discussion about 
>>schema >definition/change migration. 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.
>
>Spreadsheet Detective,
>Southern Cross Software Queensland Pty Limited
>54 Gerler Street
>Bardon, Queensland 4065, Australia.
>
>Email: [email protected]
>www.SpreadsheetDetective.com
>Ph: +61 427 830248 (Australian Eastern Standard Time)
>
>"If the model seems correct only because the numbers look right,
>then why build the model in the first place?"

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/