I see. Modeler was never intended to be a standalone ER Modeling tool. My own vision was to keep it useful for Cayenne users. Never the less, most of the things that you mentioned are directly aligned with this goal, and we can improve Modeler for everyone if we pay attention to them. For many of the questions (Object / Db layers split, general terminology, etc.) the short answer is - it is done like that because Cayenne runtime expects it to be like that. There's a story behind each one of them, but I don't see any of that changing right now.
Improving the Modeler is another story. Like Ari said, we are open to help from volunteers to make the tool better. I am personally submerged too deeply in the framework internals to do more than isolated tweaks to the Modeler, usually limited to keeping it up with new runtime features. Also there have been lots of Modeler contributions from other committers and users (entity synchronization, new preferences, diagraming tool, etc, etc. was all done by different people). This was awesome, but having someone to take a more permanent ownership of the UI tools (we also have a prototype Eclipse plugin) and make them shine would be even more awesome. And until then we'll be happy to discuss and take a la carte improvements :) Andrus On Apr 10, 2013, at 11:32 AM, Robert Huber @ 7r <hu...@seven-r.ch> wrote: > Hi Andrus > >> The goal of CayenneModeler is not abstract modeling, but rather to create a >> binding between DB and Java. So I don't quite understand how it is useful >> for you if you are not writing a Cayenne application? > > As we stopped some years ago developing with WebObjects, we continue(d) to > use the EOModeler (Entity Modeler, WOLips). As it is a nice ER Modelling tool > and works well. But now there is no or not much activity any more on the > WOLips side, I have the impression (although not sure). But anyway, We have > to get a diagram for discussions and therefor we still have an OS X 10.4 > machine with EOModeler installed, to be able to import the WOLips .eomodeld > file an print a diagram (more make a PDF an they print a big size diagram, as > there are typically more than 100 entities). But all this is not a good work > flow and we have to get a replacement. And as Cayenne Modeler can import > .eomodeld files, it's an obvious tool to look at. > > In short, we are interested in Cayenne Modeler as a standalone tool for our > database design modeling needs and to generate code (for SAP Sybase SQL > Anyhwere databases or PostgreSQL databases) > > Best regards, Robert > > >> >> I'll be happy to answer the specific questions, but I am not quite sure I >> follow your scenario. >> >> Thanks, >> Andrus >> >> >> On Apr 9, 2013, at 7:23 PM, Robert Huber @ 7r <roberthu...@sunrise.ch> wrote: >> >>> Hello Andrus >>> >>> Thanks a lot for the new release 3B2 which was the reason to try Cayenne >>> Modeler again. >>> We currently use EOModeler for all of our modelling tasks. Having tried >>> Cayenne Modeler only a little bit several times, I started seriously again >>> with this build and your getting started guide an built the Artist - >>> Gallery project to see if Cayenne Modeler could now be a successor for >>> EOModeler. >>> But I assume I have some general understanding problems. >>> >>> I would very much appreciate if you could demystify some of them. Thank you >>> a lot for your answers or hints in advance. >>> >>> Task >>> – In EOModeler, the task is to model an ER-Model. For example, I create an >>> entity, add attributes and relationships between entities. I then can add >>> column names and other implementation details as column width, type, … So I >>> make in one place the ER-Model and the mapping to the relational model. >>> – In Cayenne Modeler, it seems, one has to start with the implementation >>> side, i. e. the relational model side, and then somehow create the >>> ER-Model? So one is not exactly starting with modeling, but wit the >>> implementation? >>> >>> Some Observations/Questions >>> → Is this the intended procedure? Why doesn't it start on the modelling >>> side, i. e. the defining of entities (classes) with their attributes etc.? >>> And then allowing to map it to the relational model. >>> >>> → The splitting between the tables and classes seems quite complicate to >>> me, especially with the create ObjEntity and syncing between the two >>> «models». May be there is a reason for this separation and syncing which I >>> don't recognize? >>> >>> → When creating an ObjEntity from an DBEntity (table), the name of the >>> ObjEntity is in plural, whereas a common naming is singular for the entity, >>> e. g. Artist (as it is a set), and plural for the table, e. g. artists. >>> Unfortunatly (for me), the ObjEntity is also plural. I found it can be >>> overridden, but if one presses the green C button again, an new ObjEntity >>> in plural is created beside the existing in singular. >>> >>> → The primary key attributes are not displayed in the ObjEntity. Why not? >>> It is displayed in the >>> >>> → The column name exists in ObjEntity as DbAttribute, and in the DbEntity >>> (table) as column name, i. e. it is in two places, but can only be edited >>> in the DbEntity, not in the ObjEntity >>> >>> → Naming in Cayenne Modeler its very strange for me, as many things seem >>> mixed. For the ERM side (P.P.S. Cheng) I would have expected terms like >>> entity, attribute, relationship, sub type, super type, … and for the >>> relational model (F. Codd) I would have expected terms like table >>> (relation), column, domain, … >>> >>> → If I organize the ER Diagram and Class graphs as I like, it is set to >>> some default (even depending on the window size) after reopening the >>> project. If I organize the ER Diagram, it should absolutely keep it's >>> layout. I think this is a necessity for larger models. >>> >>> → I miss the ability to place some sort of text box in the ER Diagram and >>> to give a self defined color to the entity (class) or table. >>> >>> → I did not find EOPrototypes, a great concept for applying DB types for >>> quickly porting a model to a new database. I really have problems if this >>> is not available. >>> >>> As I would primarily use the Cayenne Modeler (as we work with Servoy, we >>> will not use the Cayenne Framework), I am at the moment not comfortable to >>> make the switch from EOModeler to Cayenne Modeler. I am very much aware >>> that making such a tool is a lot of work and appreciate it in every way. So >>> the above points are not meant as a critic but a way to find out if Cayenne >>> Modeler could be a successor tool for us. I am also a bit unsure for what >>> tasks exactly Cayenne Modeler is really meant? >>> >>> Thanks and best regards, Robert >>> >>> >>> >>> _/ _/ _/ _/ _/ r. huber >>> _/ >>> _/ _/ _/ 7r gmbh >>> _/ _/ _/ alpenstrasse 93 >>> _/ _// ch-8200 schaffhausen >>> _/ _/ >>> _/ _/ tel. +41 52 624 81 15 www.seven-r.ch >>> >>> >>> >>> On 12.06.2012, at 13:17, Andrus Adamchik wrote: >>> >>>> Very happy to announce Cayenne 3.1 beta! The full announcement can be >>>> found here: >>>> >>>> http://cayenne.apache.org/2012/06/12/cayenne-31-beta-released.html >>>> >>>> Download is here of course: >>>> >>>> http://cayenne.apache.org/download.html >>>> >>>> A note on 3.1 documentation. The new PDF guides shipped with the download >>>> document all the new features, and some of the old ones. However they are >>>> still work in progress. I suggest still checking the PDFs, as they are the >>>> only source of information on the DI, configuration properties and the new >>>> way to start Cayenne runtime, but go back to 3.0 HTML docs whenever you >>>> find a gaping hole in the PDF: >>>> >>>> http://cayenne.apache.org/doc30/overview.html >>>> >>>> We should finish the docs by the time 3.1 is final. >>>> >>>> Cheers, >>>> Andrus >>> >>> >> >> > >
