Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Modeling MySQL views and primary keys
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: 
 <CA+Bndfs3CJ4zX2TQcMDFq6JWWQ91BEWyLK6Yzw8i79SNOT6S6w@mail.gmail.com>
Date: Sun, 5 Feb 2012 10:24:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <253AC93F-B159-4517-B630-D569F7A9DEF5@objectstyle.org>
References: 
 <CA+Bndfs3CJ4zX2TQcMDFq6JWWQ91BEWyLK6Yzw8i79SNOT6S6w@mail.gmail.com>
To: user@cayenne.apache.org

AFAIK there's no way to tell the Modeler to ignore certain manual model =
tweaks when creating migrations. Things like that are the reason why I =
am using manual SQL-based migrations to evolve my schema.=20

Andrus

On Feb 4, 2012, at 3:11 AM, Tad wrote:

> We've got an existing MySQL 5.x database that contains a single view. =
This
> view includes the primary key column of its source table in its =
results.
>=20
> When modeling this view with a db-entity (through re-engineering,
> migration, and manual creation) the modeler tells us that the entity =
lacks
> a primary key column (even though the modeler picks up the column and =
adds
> it as an attribute). So, we assign the appropriate PK column, and this
> error disappears.
>=20
> The problem now is that any future migrations attempt to alter the =
view and
> add a primary key (using ALTER TABLE, no less), and we have to know =
not to
> apply these changes to the database schema.
>=20
> Is there a way to suppress this behavior? Perhaps by ignoring the view
> entirely, or adding something to the view definition itself to assign =
the
> "primary key" attribute to a column of its results?
>=20
> Thanks for any help.
>=20
> -Tad Fisher