Re: Re: Mapping views with modeller

From: Gary Jarrel (garyjarre..mail.com)
Date: Thu Jul 08 2010 - 00:44:13 UTC

  • Next message: Andrus Adamchik: "Cayenne 3.0 in the Media"

    On Wed, Jul 7, 2010 at 11:48 PM, matero <mater..mail.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



    This archive was generated by hypermail 2.0.0 : Thu Jul 08 2010 - 00:45:50 UTC