I assume that SELECT should be build with <key>s used in WHERE clause?
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]
