RE: TEMP column created via set_sql and MySQL DATE_FORMAT function returns 0 in Class::DBI but valid data from command-line

[prev] [thread] [next] [Date index for 2005/02/15]

BINGO!!!! Thanks. I backslashed them last night when I guessed by the
same token but I guess I was escaping for the wrong interpreter.

1/ Something needs to be documented in the "DEFINING SQL STATEMENTS"
section of the docs about this. What part of Class::DBI is taking a
string bracked with q{} and evaluating symbols prefaced with a %?

2/ Something else about the docs. In the "TABLE RELATIONSHIPS" section,
both has_many and might_have start with an abstract description of their
calling convention:

	Class->has_many(method_to_create =3D> "Foreign::Class");

	Music::CD->might_have(method_name =3D> Class =3D>
(@fields_to_import));

But has_a lacks such an abstract description and you have to read really
hard to infer the calling conventions. I propose one line showing the
abstract calling convention be added:

	 Music::CD->has_a($method_name =3D> $package_to_access);


> -----Original Message-----
> From: Tim Bunce HM=20
> Sent: Tuesday, February 15, 2005 2:39 PM
> To: Terrence Brannon
> Cc: cdbi-talk@xxxxxx.xxxxx.xxx
> Subject: Re: TEMP column created via set_sql and MySQL=20
> DATE_FORMAT function returns 0 in Class::DBI but valid data=20
> from command-line
>=20
> On Mon, Feb 14, 2005 at 02:31:30PM -0800, Terrence Brannon wrote:
> > I am using mysql's DATE_FORMAT function to make a datetime column=20
> > human-readable. Cutting and pasting the SQL in a set_sql statement=20
> > from a Class::DBI package works fine. However, when I attempt to=20
> > access this column as a TEMP column, the date comes back as=20
> double zeros.
>=20
> > __PACKAGE__->set_sql(recent_results =3D> qq{=20
> >    SELECT DATE_FORMAT(creation_datetime,'%b %d') as battle_date,
>=20
> I'd take a guess that those percent symbols need to be=20
> escaped, probably by doubling them in standard sprintf style:
>=20
>      SELECT DATE_FORMAT(creation_datetime,'%%b %%d') as battle_date,
>=20
> But it's just a guess.
>=20
> Tim.
>=20
>=20