I don't mind having the mapping (DataMap) in a single file, although
perhaps it might make merging harder if two people are editing the
same model simultaneously. And I wasn't really suggesting splitting
it out into a file-per-entity, like in EOModeler. I was talking about
grouping all current Cayenne XML (Domains, Maps, Nodes) files in a
single directory wrapper. This would make it easier to make quick
copies of a model before you changed something if you wanted (for
whatever reason). Of course, if an SCM system is in place, you have
to deal with the directory quirks of the system if you actually want
to rename or move the file, but that argument could be made about
refactoring any bit of the system. It would also be easier to send a
copy of the model to someone who isn't set up with the SCM system
(like DBAs, etc). They could use the modeler to view the model or,
and this is what I'm looking at currently, be able to edit the
database with another tool (I've started designing a DBEdit clone that
would work with Cayenne Models -- DBEdit is currently dead on Leopard
and is an invaluable tool for database-related software development
and production support). The branding issue is secondary, although it
would be nice to double-click on a model and have it open in CM.
Thanks,
/dev/mrg
PS. Not all models are simple, either -- one of mine had 8 XML files,
but would've had more if I weren't creating DataMaps at runtime ...
made the root a bit messier.
On Dec 19, 2007 11:40 AM, Andrus Adamchik <andru..bjectstyle.org> wrote:
> I just remembered some background BTW. The conclusion I came to in the
> message below is the same one we made in 2001 when we approached the
> initial Cayenne design. The group of people involved all did
> WebObjects development on Windows, and used CVS (which is rather
> directory-unfriendly). So the feeling was that having mapping in a
> single file is a usability feature compared to EOF. Since we are not
> going to split map.xml any further, look at it this way: it makes
> sense to have an .emodeld folder for EOF as it had one mapping file
> per entity... it does not for Cayenne.
>
> Andrus
>
>
>
>
> On Dec 19, 2007, at 6:27 PM, Andrus Adamchik wrote:
>
> > Not saying yes or no just yet, but let me comment on the specific
> > items.
> >
> >> * Have Cayenne Modeler save the XML files (cayenne.xml, etc) into a
> >> Cayenne wrapper directory of your naming, such as MyModel.cayenne (it
> >> would append the .cayenne, which is the wrapper signature). You
> >> could
> >> also have MyOtherModel.cayenne in the same directory.
> >
> > Currently you can have multiple cayenne.xml files either in
> > different packages or in the root of different jars (of course this
> > will only becomes really useful once we implement CAY-943). Having
> > multiple cayenne.xml in a single jar doesn't buy you much really...
> >
> >> * Have Cayenne resolve all *.cayenne wrappers at the root of the
> >> CLASSPATH upon startup.
> >
> > How are you planning to do that? The only environment independent
> > way that I know of in Java is "ClassLoader.getResources(String)"
> > which requires an exact name, not a pattern. This would work for
> > multiple cayenne.xml in the root of different jars, but won't work
> > for "*.cayenne" (there are some workarounds that may potentially
> > limit portability).
> >
> >> * The *.cayenne wrapper directories could be "branded" with a Cayenne
> >> logo (at least on OS X, not 100% sure about other OS's).
> >
> > This would be an OSX only feature.
> >
> >> * The *.cayenne wrapper can be double-clicked to launch Cayenne
> >> Modeler (again, on OS X, hopefully on other OS's too).
> >
> > This one too.
> >
> >> * It is easier to copy a model around in a GUI (drag and drop one
> >> "file") instead of select multiple files.
> >
> > True, although usually you'd have .svn in your folder, so you do not
> > want to copy that.
> >
> >> I can't think of any real negatives to this, either,
> >> but feedback is greatly appreciated.
> >
> > The biggest negative to me is that we introduce extra complexity
> > without a clear advantage. I am worried of Cayenne turning into Perl
> > with multiple redundant ways to solve any given problem (note that
> > usually I am the one guilty of this .... for instance now we have 3
> > types of persistent objects).
> >
> > Anyways, we have to weigh potential benefits against this concern.
> > And the only benefit I am seeing so far is branding on OS X which is
> > probably the least of our concerns.
> >
> > Andrus
> >
>
>
This archive was generated by hypermail 2.0.0 : Wed Dec 26 2007 - 10:16:14 EST