Vadim Gritsenko wrote:
>
> I assume that SELECT should be build with <key>s used in WHERE clause?
Absolutely. We do want to get the propper record from the DB.
>
> Vadim
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, July 27, 2001 2:41 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [BUG C2] act method of Database Actions always return null
> >
> >
> > Vadim Gritsenko wrote:
> > >
> > > > -----Original Message-----
> > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, July 27, 2001 10:59 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [BUG C2] act method of Database Actions always return null
> > > >
> > > >
> > > > Vadim Gritsenko wrote:
> > > > >
> > > > > Berin,
> > > > >
> > > > > I think that you as author of this actions know the answer on my question:
> > > > >
> > > > > I'm thinking of returning number of updated rows in
>Database[Update|Delete]Action as a result.
> > > > > Name of result parameter in the map would be "rows". Is it OK - should I
>commit the changes?
> > > >
> > > > Sure--as long as you keep two things in mind:
> > > >
> > > > 1) Never return a map if the query failed
> > > > 2) The returned map has substitution values for the sitemap. I doubt you will
>be
> > > > selecting stylesheets based on the number of rows updated. Perhaps it would
> > > > be better to set Request attributes instead.
> > >
> > > Makes perfect sence! Done. Return result is empty Map on success and row count
>as request
> > > attribute, "null" if nothing has been changed, and exception for all other cases.
> >
> >
> > Cool beans!
> >
> > If you are up to the task, I have one more DatabaseAction that would make Cocoon
> > Form processing really easy. It is a DatabaseSelectAction that uses the same
> > exact format as the other database actions, but creates a SQL SELECT query.
> > When it is run, the Action:
> >
> > 1) tests to see if there is a Request _parameter_ by the same name as specified in
> > the configuration file.
> >
> > 2) If it does, it populates the Request _attribute_ by the same name with the
> > Request _parameter_ value.
> >
> > 3) If it does not, it populates the Request _attribute_ with the value from
> > the database.
> >
> > 4) It will return a Map on success, and a null if there was an error. Note:
> > no results is not an error case.
> >
> >
> >
> > What this accomplishes is a process where you have a form whose values are
> > consistent with what the user typed in--without writing alot of custom code
> > for it. I have an existing webapp that needs to be upgraded in the very near
> > future that does not handle this properly. Basically it always gathers the
> > information from the database even if there was an error condition. The
> > implications are that if you entered or changed 10 items on the form, and one
> > of them caused an error, they would all be set back to the original values.
> > With the new action we can avoid that--and if written correctly we can
> > even avoid calling the SQL until there is a request parameter that isn't
> > matched!
> >
> > Any takers?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
