hibernate-devel

[Hibernate-devel] MappingByReflection release

[Doug C. <de...@fl...>]

I have made the first release of MappingByReflection to the cvs.

MappingByReflection is a command line tool for creating an O-R Mapping
XML from the .class files of the classes to be persisted. It is still
incomplete, and undoubtedly has problems, but I would appreciate it if
you tried to use it and report any problems you experience to this
list. See known limitations and problems below.

There is no user documentation yet, but there is some javadoc in the
file cirrus/hibernate/tools/reflect/MappingByReflection.java.

MappingByReflection takes a list of fully specified classes, which
must be compiled and present on classpath, and produces the O-R
Mapping. The classes can be specified on the command line, or in an
interactive loop. One advantage of the interactive loop is that you
can specify the UID of each class individually; this makes it possible
to put subclasses in separate tables. I plan to add this capability to
the command line version shortly.

If anyone would like to volunteer to add a GUI face to
MappingByReflection I would be delighted to support you.

It is only necessary to specify the "fringe" of the class inheritance
tree to get all necessary superclasses added to the mapping.
MappingByReflection chases the superclass chain until it finds the
specified or default UID property. See javadoc for details.

MappingByReflection uses several heuristics to decide the type of each
property. Again, the javadoc tells all.

Known limitations and problems...

- non-primitive array elements are not handled correctly
  (this will be fixed soon)
- no lazy attribute for collections
  (should be the default? this will be fixed soon)
- no length attribute for string/blob/binary/serializable
  (should be the default? this will be fixed soon)
- no toplevel collections
  (I don't know any way to find them by reflection)
- cannot see inside Set Map or List properties
  (this is a feature of hibernate's opaque lazy collections)

I *will* add more options for the GUI if you ask. In particular, there
is already provision for per class customization of the select mode,
the depth of component recursion, and the candidate UIDs.

Have fun!

e

[Hibernate-devel] Re: MappingByReflection release

[Phillip B. <phi...@cl...>]

Hi Doug,

I was thinking an Ant task might be more useful than a GUI.  I could 
then combine this with a task to drive DBSchemaExport and then the 
building of the mapping and generating a db schema becomes just two 
clicks in my IDE - call me lazy :-)

On the MappingByReflection side of things all that would be required is 
a method to accept a String[] of class names to be mapped, a File for 
the mapping to be written to and the uid argument. This method would 
also need to throw an exception if a mapping fails or there is an 
IOException with the XML file.

Any one see any negatives?

Phillip B.

[Hibernate-devel] Re[2]: MappingByReflection release

[Doug C. <de...@fl...>]

> I was thinking an Ant task might be more useful than a GUI.

They would both be useful...

>   I could
> then combine this with a task to drive DBSchemaExport and then the 
> building of the mapping and generating a db schema becomes just two 
> clicks in my IDE - call me lazy :-)

Unfortunately this is unlikely to work; the MappingByReflection code
will probably never be strong enough to get 100% of the mapping. In
some cases it might, but it will be the exception. Currently there is
no way to generate a top-level collection, for example, and there
probably never will be. Other aspects of the mapping cannot be
determined by reflection, so the GUI tool would be useful to fine tune
the mapping.

> On the MappingByReflection side of things all that would be required is 
> a method to accept a String[] of class names to be mapped, a File for 
> the mapping to be written to and the uid argument. This method would 
> also need to throw an exception if a mapping fails or there is an 
> IOException with the XML file.

I think an ant task like this would be useful to get the initial
mapping which could be massaged by hand. A second ant task could pass
the mapping through DBSchemaExport afterward.

Other suggestions to give MappingByReflection more info have included
a configuration file, a javadoc tag processor, more extensive property
name and typing heuristics, class file disassembly, and my favorite,
the GUI tool.

e

Re: [Hibernate-devel] Re[2]: MappingByReflection release

[Phillip B. <phi...@cl...>]

[snip]

>Unfortunately this is unlikely to work; the MappingByReflection code
>will probably never be strong enough to get 100% of the mapping. 
>
Suspected that.would be the case - nothing is ever that easy. :-(  

[snip]

>I think an ant task like this would be useful to get the initial
>mapping which could be massaged by hand. A second ant task could pass
>the mapping through DBSchemaExport afterward.
>

The Ant task I mentioned is underway.  It probably will not see the 
light of day till around mid-week.  I'll then give hit the DBSchema task 
after this.

As I'm not a fan of coding XML by hand, I'd still like to find a mapping 
generation mechanism that fits into an automated build environment.  I 
have reservations about layering explicit mapping details over to the 
top of MappingByRefection.  It reminds me of 4GL languages where you 
have a bunch of implicit behaviour that you can override with explict 
options.  The reservation I have with this is it can often be harder 
figuring out how to override the implicit behaviour than writing explict 
code from the start.  I'm not saying this will be the case with 
MappingByReflection, its just something to keep in mind.

For complete explict mappings I'm thinking Javadoc tags would be the way 
to go.  In the archives Paul Szego mentions a doclet he's written that 
will take Javadoc tags and output a mapping file.  Paul, is this able to 
be added to CVS?  The other option for Javadocs as suggested by Ralf 
Purnhagen is an xdoclet template - at this stage however this may be 
reinventing the wheel Paul has already made.

Phillip B.

Re[2]: [Hibernate-devel] Re[2]: MappingByReflection release

[Doug C. <de...@fl...>]

[snip]
> As I'm not a fan of coding XML by hand, I'd still like to find a mapping
> generation mechanism that fits into an automated build environment.  I 
> have reservations about layering explicit mapping details over to the 
> top of MappingByRefection.

One of the best things about MappingByRefection is that it will (when
it's tested) only produce mappings that will work... at least on the
Java side, and with newly created databases. In other words, you can't
have a property in the xml that doesn't exist in the class, and they
always have a good type. I hope that when adding information in an
automated way, by whatever means (gui, javadoc, config file), that
this feature is maintained.

e