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]>
