Editing a database record best practice?

[Ryan Cornia <rc...@utah.gov>]

A common scenario I run into is having a web application where the user needs to edit a database record.

The simplest approach I can find is this -
1.) Load the db record into a bean. Copy the bean props. to the form for display. Put the dbbean in the session. 

2.) Show the form, when the user presses "save", validate the form, make sure, if possible, that the form primary key fields are equal to the dbbean in the session primary fields. 

3.) Have the dbbean do an update statement. In order to do this properly, the dbbean needs to have kept the original db values so they can be put in a where clause. This insures that we are changing the record exactly as we loaded it. If somone made a change before the page was submitted, the update would fail.

Is that the best approach to accomodate a sort of "optomistic locking"? Are there any tools to autogenerate the dbbean objects? I was thinking of trying to do it with an xml schema and XSLT to transform the schema to java objects. Thoughts? 

Thanks,
Ryan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Editing a database record best practice?

[stf <s....@vierundsechzig.de>]

we are using a similar approach with  ejb's, that produce value object's
instead of database records: We have generic ValueObjects that are filled
into the formBean using reflection (You can do something similar with
result-sets using the meta-data: as long as you don't mind tying your
bean-properties to the database-field names...): along with the data, a
timestamp is transported inside the value-object: So only the ValueObject
with the last timestamp can make an update on the ejb (with only some
exceptions (CLOb/BLOB-fields which get specific update methods) we make
global updates, we just set *all* values from the value-object into the ejb.
Coming back from the form the process works the other way round: copying the
values from the ActionForm into the valueObject and then passing it to the
ejb for update...

This sounds like a lot of copying: We first had the ejb's producing
ValueObjects that extended action-forms with all the fields needed in the
form: we ended up with having to package the struts-libs with every EJB
caused by this mixing of business-object and view-layer (resulting in a lot
of classloading-hassle: Fortunately you sometimes get real errors for bad
design-decisions..)  - so we ended up with this generic ValueObjectLayer
that  clearly separates the view from the Business-objects.

Instead of using ejb you can try jdo (e.g castor, or intelliBO) - I'm not
really sure, wether the need for such a neutralizing layer vanishes with
this, but I think they will give you at least some handy tools to write the
Data-Access-layer without having to write the sql by yourself.

greetings
stf
----- Original Message -----
From: "Ryan Cornia" <rc...@utah.gov>
To: <st...@jakarta.apache.org>
Sent: Tuesday, February 12, 2002 2:56 AM
Subject: Editing a database record best practice?


> A common scenario I run into is having a web application where the user
needs to edit a database record.
>
> The simplest approach I can find is this -
> 1.) Load the db record into a bean. Copy the bean props. to the form for
display. Put the dbbean in the session.
>
> 2.) Show the form, when the user presses "save", validate the form, make
sure, if possible, that the form primary key fields are equal to the dbbean
in the session primary fields.
>
> 3.) Have the dbbean do an update statement. In order to do this properly,
the dbbean needs to have kept the original db values so they can be put in a
where clause. This insures that we are changing the record exactly as we
loaded it. If somone made a change before the page was submitted, the update
would fail.
>
> Is that the best approach to accomodate a sort of "optomistic locking"?
Are there any tools to autogenerate the dbbean objects? I was thinking of
trying to do it with an xml schema and XSLT to transform the schema to java
objects. Thoughts?
>
> Thanks,
> Ryan
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>