DatabaseSelectAction, Was: [BUG C2] act method of Database Actions always return null

[Vadim Gritsenko <vg...@hns.com>]

DatabaseSelectAction is checked in into HEAD branch.

There is one outstanding issue though:
getColumn returns Object, and getParameter returns String.
Either String must be converted into an Object, or Object - to String.
Right now, (it is simle to do) I'm converting Object to String, so all
attributes in request are String objects (lines 99 and 126 in select action).

And: Absent (null) request parameter and empty ("") request parameter are treated
same: data obtained from DB.

Vadim

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, July 27, 2001 4:23 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [BUG C2] act method of Database Actions always return null
> 
> 
> 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:bloritsch@apache.org]
> > > Sent: Friday, July 27, 2001 2:41 PM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: Re: [BUG C2] act method of Database Actions always return null
> > >
> > >
> > > Vadim Gritsenko wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > > > Sent: Friday, July 27, 2001 10:59 AM
> > > > > To: cocoon-dev@xml.apache.org
> > > > > 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: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org