Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Subject: Re: Case-sensitivity problems with columns (DbAttributes)
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: 
 <CAOUwSGueXPZzmjsLm246Ld5dMsk1mAoi7ndcYZRy1DmWLOAYHw@mail.gmail.com>
Date: Mon, 15 Jun 2015 18:15:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1869388-BB52-4E75-9A77-130A0BB11460@objectstyle.org>
References: 
 <CAOUwSGueXPZzmjsLm246Ld5dMsk1mAoi7ndcYZRy1DmWLOAYHw@mail.gmail.com>
To: dev@cayenne.apache.org

Hi John,

IIRC you can force PostgreSQL (or any other DB really) to treat column =
names as case-sensitive by including them in double quotes when creating =
and querying the tables. In Cayenne this means setting "Quote SQL =
Identifiers" to "on" in the DataMap and using explicit double quotes in =
SQLTemplate.

Not going to help with "SELECT * FROM", but should address all other =
cases.

> Like forcing or providing a switch to ensure DbAttribute names are
> lowercase?

If the above doesn't help, you can probably decorate DataMapLoader =
service to conditionally convert loaded DataMap to lower case =
DbAttributes (if you can access DataSource and determine DB type prior =
to project loading), or do that in the EntityResolver after =
ServerRuntime startup (less clean, but same end result).

Andrus


> On Jun 13, 2015, at 12:13 AM, John Huss <johnthuss@gmail.com> wrote:
>=20
> I've run into problems a few times caused by case-mismatch issues with
> columns (DbAttributes).
>=20
> The primary one being when I have SQLTemplate queries that return =
actual
> DataObjects.  If the DbAttribute is declared with mixed case =
(myTablePK)
> then my query just returns a list of nulls because it can't find the =
pk
> field to create an ObjectId.  I'm using postgres mostly which is not
> case-sensitive and returns the columns in lowercase it seems.
>=20
> What do you think about changing some of this behavior?
>=20
> Like forcing or providing a switch to ensure DbAttribute names are
> lowercase?
>=20
> Or doing more intelligent matching that ignores case as much as =
possible?
> I.E. if there are no duplicate columns when ignoring case, then ignore =
case?
>=20
> John