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 <[email protected]> > On Wed, Jul 7, 2010 at 11:48 PM, matero <[email protected]> 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 >
