Gary, thanks for your aclarations, they cleared mi mind...
after I let my questions out I find some of the answers (like the read-only
objects) myself...
I should learn to do less questions and more reading :(
I expect to return something to cayenne some day :)
regards
Juanjo
2010/7/7 Gary Jarrel <garyjarre..mail.com>
> 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 - 11:21:29 UTC