You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2001/09/01 18:27:15 UTC
Re: [PATCH] small patches to torque in 2.1
Fedor Karpelevitch <fe...@Barra.COM> writes:
> 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems to
> work well and solves all the inherent problems with dates.
Forward ported to jakarta-turbine-3 into SqlExpression and DB.
SqlExpression relies on DB to do the formatting, so I slapped the
escape in as the default formatting mechanism (i.e. the toDateString()
method).
John, if you have a moment to look over this change, I'd appreciate
it.
> 2) reverted my change to DateKey.toString() - it was an attempt to solve the
> problem above, but did not work out very well. With the fix above it is no
> longer needed, and it was causing inconsistent behaviour - toString()
> results were different depending on the history of the DateKey.
Ported.
> 3) added save(String) and save(DBConnection) methods to Persistent interface
> so that it is enough to cast an object to Persistent to use those methods.
Ported. Torque-generated OMs implment these methods.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH] small patches to torque in 2.1
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Fedor Karpelevitch <fe...@apache.org> writes:
> On 1 September 2001 09:27, you wrote:
> > Fedor Karpelevitch <fe...@Barra.COM> writes:
> > > 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems
> > > to work well and solves all the inherent problems with dates.
> >
> > Forward ported to jakarta-turbine-3 into SqlExpression and DB.
> > SqlExpression relies on DB to do the formatting, so I slapped the
> > escape in as the default formatting mechanism (i.e. the toDateString()
> > method).
>
> I do not think toDateString() is needed at all since JDBC escape should work
> fine for *any* database. I think it can be dropped (deprecated first).
The only use case which I can think of for it is to handle JDBC
drivers which don't implement JDBC escapes. John, I believe that's
your method--comments?
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [PATCH] small patches to torque in 2.1
Posted by Fedor Karpelevitch <fe...@apache.org>.
On 1 September 2001 09:27, you wrote:
> Fedor Karpelevitch <fe...@Barra.COM> writes:
> > 1) implemented Gonzalo's suggestion to use JDBC escapes for dates. Seems
> > to work well and solves all the inherent problems with dates.
>
> Forward ported to jakarta-turbine-3 into SqlExpression and DB.
> SqlExpression relies on DB to do the formatting, so I slapped the
> escape in as the default formatting mechanism (i.e. the toDateString()
> method).
I do not think toDateString() is needed at all since JDBC escape should work
fine for *any* database. I think it can be dropped (deprecated first).
fedor.
>
> John, if you have a moment to look over this change, I'd appreciate
> it.
>
> > 2) reverted my change to DateKey.toString() - it was an attempt to solve
> > the problem above, but did not work out very well. With the fix above it
> > is no longer needed, and it was causing inconsistent behaviour -
> > toString() results were different depending on the history of the
> > DateKey.
>
> Ported.
thanks.
>
> > 3) added save(String) and save(DBConnection) methods to Persistent
> > interface so that it is enough to cast an object to Persistent to use
> > those methods.
>
> Ported. Torque-generated OMs implment these methods.
thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org