cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Jarrel <garyjar...@gmail.com>
Subject Re: Re: Mapping views with modeller
Date Thu, 08 Jul 2010 00:44:13 GMT
On Wed, Jul 7, 2010 at 11:48 PM, matero <matero@gmail.com> wrote:
> Thanks Andrus.
>
> So, to map a view, I need to  create it on my DB, then import it with the
> modeler and then map it.
> Or I should create the DbEntity as a normal one (putting all its attributes as
> read-only) ?

If you have a view in the database you can reverse engineer it into
the Cayenne Modeler and the modeler will create both the DB and the
OBJ entities for you. Alternatively you can do the whole process
manually by creating a db entity having the same name as your view and
then map each attribute in the modeler to the respective attribute in
the view. Then you create your object entity and map it to the
database entity via the Table/View option and then you can sync the
object entity so that it picks up all the fields from the view.

> Is it possible from the meta-model maintained by cayenne determine if an
> ObjEntity maps a table or a view? this could be used to define which class
> extend in the velocity template avoiding update / insert operations.
> If it is not possible, then I should used some kind of convention on
> tables/views names but I prefer to use the cayenne meta-model.

Not all views are read only, we commonly use views to update things in
the database (but not all database would support updating through
views) however any object entity can me made a "Read Only" entity by
specifying that it's "Read Only" in the modeler. And in this instance
the class generator (which uses velocity templates) will not generate
the setter methods.

> Finally, is there a way to tell the modeler "don't try to assign a PK to this
> kind of entity" (in hibernate there is a "assigned id" strategy whih does this).

We tend to include some unique identifier in any given view that we
use. When we take this approach we set the "PK Generation Strategy" to
"Database Generated" (in the DB entity) and let the database handle
the rest.

Otherwise (and I could be wrong here) you can leave out specifying the
Primary Key in the DB entity and leave the "PK Generation Strategy" at
default hence nothing would be generated since there is no Primary
Key. However I don't think this is such a good idea at all.

Hope this helps.

gary

Mime
View raw message