Craig, It's good to see some MySQL bashing from a Sun guy :-). I'm guessing you don't express that view too often working for the company that proclaimed "Unbreakable MySQL is the future". No views, triggers, stored procedures, disdain for people who want views...what a joke.
Dave >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: RE: Persistence Framework Comparison? >Date: Fri, 4 Oct 2002 15:18:50 -0700 (PDT) > > > >On Fri, 4 Oct 2002, Joe Barefoot wrote: > > > Date: Fri, 4 Oct 2002 15:00:04 -0700 > > From: Joe Barefoot <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > Subject: RE: Persistence Framework Comparison? > > > > > -----Original Message----- > > > From: Robert J. Sanford, Jr. [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, October 04, 2002 3:00 PM > > > To: Struts Users Mailing List > > > Subject: RE: Persistence Framework Comparison? > > > > > > > > > There are two things that I want/need in a persistence > > > framework and I have > > > yet to find them. I know that OJB does not support them and I have not > > > looked very hard at the others. Maybe you can tell me if your product > > > handles them. > > > > > > 1) Read only attributes so that a setter method is not automatically > > > generated for one and that value is never persisted, just read. > > > > So delete the setter(s) you don't want from your entity objects. Or > > just make them empty methods that don't actually do anything. > > > >You mean cut them out of the generated source code manually? Every time >you add a new column and regenerate? Yuck ... > > > > > > > 2) The ability to persist an object to a different "table" > > > than it was read > > > from. Yes this seems odd so let me explain in a few simple > > > words followed by > > > a simplistic example. The simple words are - performance and > > > simplicity. > > > When developing a web app database I tend to go for normalization. The > > > employees are in one table with a FK to the department table. > > > But, when > > > displaying the data on a page I want to display the name of > > > the department, > > > not its database ID. So, I use a view that joins the two > > > tables meaning that > > > a) I get all the data that I need in a single query I can > > > get all of the information I need for display (performance) > > > and... > > > b) I don't have to worry about reading data from multiple > > > queries and/or multiple objects (simplicity). > > > > > > But, I cannot guarantee that the view I am reading from is > > > updateable so I > > > > > > How can you not guarantee this if you are creating the data model? I > > don't understand. > > > >Not all databases let you update through a view, even if the data model >would otherwise allow it. (Of course, there are even "databases" like >MySQL that don't have views at all, but I digress :-). > >Craig > > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
