Re: Why are my col names lowercased?
[prev]
[thread]
[next]
[Date index for 2004/10/13]
--=-Wh1Q3+HXkZ1GhKkAwbKQ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Wed, 2004-10-13 at 15:26, Perrin Harkins wrote:
> On Wed, 2004-10-13 at 14:56, Sean Quinlan wrote:
> > In an application I'm working on, I'm copying all the values for a
> > particular objects attributes into an aggregate data structure,
which
> > will be used elsewhere to populate a form. Everything seemed to be
> > working fine - but for some reason none of the values appeared in
the
> > form. Eventually I dumped the data structure, and discovered lower
cased
> > keys for the column names which had the expected values.
>=20
> This is caused by the NAME_lc default parameter -- see the
"connection"
> section of the POD. You can change it, although you will currently
have
> to change a line in sth_to_objects() as well where it gets used.
Thanks! Missed that in the pod, sorry. I'll look into this when I have a
bit of time. Anyone working on a patch so that changing the parameter
alone does the trick? If not, I'll try to generate one if I get to this.
> > My only guess is that for some reason someone thought it was
desirable
> > to have capitalization typos in accessing data be ignored, or
something
> > equivalent?
>=20
> I'm guessing it was to normalize column names because they can come
back
> with the capitalization used in the query in some databases which are
> not case-sensitive.
If the database is not case sensitive, what would it matter to change
the column names? I think I misunderstood you.
> > Now I have hundreds
> > of lines of code using data structures, forms, etc that use the
column
> > names as defined.
> >=20
> > I really don't want to have to hand code the column names inside the
> > app.
>=20
> Hmm, you don't want to hand-code the column names but you already have
> hundreds of lines of code that use them? You lost me there.
lol! Yeah yeah. I'm not quite clever enough (or haven't found quite the
right tool) to dynamically generate well laid out web forms. So there
are some places where I do refer to specific columns, such as in
returning a form, or doing some specific operation on the value of a
specific column.
However I also have many places, such as the method I was working on
that prompted this message, where I'm working on code that is
sufficiently generalized (and hopefully reusable) that I try not to hard
code anything (like columns names, paths, whatever). I suppose it would
have been more concise to write something like 'I really don't want to
hand-code the column names inside an otherwise generalized method'.
Daniel's response, while not directly applicable, functionally
demonstrated tools which elucidated a way to make only a small change to
the current code and get the results I had expected.
my @cols =3D $obj->columns;
@{$HR_data}{@cols} =3D $obj->get(@cols);
Became:
my @cols =3D $obj->columns;
@{$HR_data}{map{$_->name} @cols} =3D $obj->get(@cols);
I am of course making the assumption here that values are returned in
the same order as the array of column names. But the docs and a few
tests seem to support that assumption.
Thanks everyone!
--=20
Sean Quinlan <seanq@xxxxxx.xx.xxx>
BMERC, Boston University
--=-Wh1Q3+HXkZ1GhKkAwbKQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBBbZlUnv2yYfTgGZsRAsjPAJ9EEp2167qdSZUqgJi8CJ7wUM6fsACfWPNL
a2L9pVhjRoJrysAL4CmwHwo=
=HoWM
-----END PGP SIGNATURE-----
--=-Wh1Q3+HXkZ1GhKkAwbKQ--