hibernate-devel — development

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[3]: [Hibernate-devel] subcollection v collection

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

Earler I said:

> your name           my alternative
> <collection>        <collection>
> <subcollection>     <collection-element>
> <component>         <component>
> <composite-element> <component-element>
> new                 <nested-component>

another option

<collection>        <collection>
<subcollection>     <collection-element>
<component>         <component>
<composite-element> <composite-element>
new                 <composite>

e

[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[2]: [Hibernate-devel] subcollection v collection

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

> On second thoughts, renaming subcollection like that would _not_ be a good
> idea. <subcollection> has *no* name attribute, <nested-composite-element>
> specifically has one. Aaaarrrhhhh..... :)

I haven't thought it through completely, but

property := named member of class
element  := member of collection (not named)

your name           my alternative
<collection>        <collection-property>
<subcollection>     <collection-element>
<component>         <component-property>
<composite-element> <component-element>
new                 <nested-component-property>

Now if we assume "-property" is inferred...

your name           my alternative
<collection>        <collection>
<subcollection>     <collection-element>
<component>         <component>
<composite-element> <component-element>
new                 <nested-component>

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.

Re: [Hibernate-devel] subcollection v collection

[Gavin_King/Cirrus%<CI...@ci...>]

On second thoughts, renaming subcollection like that would _not_ be a good
idea. <subcollection> has *no* name attribute, <nested-composite-element>
specifically has one. Aaaarrrhhhh..... :)

Re: [Hibernate-devel] subcollection v collection

[Gavin_King/Cirrus%<CI...@ci...>]

> <!ELEMENT composite-element ( (property|many-to-one|collection|composite-
> element)* )>
>  <!ATTLIST composite-element class CDATA #REQUIRED>

> should be

> <!ELEMENT composite-element
( (property|many-to-one|subcollection|composite-
> element)* )>
> <!ATTLIST composite-element class CDATA #REQUIRED>

Oooh you had me scratching my head, thinking you were right for a second
there. But I think a made a different mistake in the DTD.

> Subcollections are not mentioned in the tutorial;

woops that needs fixing. damn looks like I was way too quick off the mark
with yesterdays file release :( Taking "release early, release often" to
heart....

> I am assuming that
> the difference between a collection and a subcollection is that a
> collection has a name (which is the name of its property of the
> containing class) whereas a subcollection is self-identified as it is
> part of a collection.

Yes - the difference *is* the name attribute. In which case a
collection held inside a composite-element is a <collection>, not
a <subcollection>. The name attribute refers to a property of the
composite element.

> This is similar to the difference between a
> component and a composite-element.

In fact, there is a bigger difference between <component> and
<composite-element>. A <component> may define a collection nested
beneath it using <set>, <map>, <list>, <array>, <primitive-array>.
<composite-element> may NOT. (The obvious semantics of this
would be pathological.) We must constrain collections and (nested)
composite elements to contain only other composite elements and what
Doug earlier called "top-level" collections. I like this name much
better than the nomenclature used in the tutorial.

Now, what _is_ broken in the DTD as it stands (and has been broken
since version 0.9.2) is <composite-elements> inside <composite-elements>.
There is no name attribute, so we can't specify what property of the
nesting class refers to the nested class.

We could fix it quickly, by adding an optional name attribute to
<composite-element> but then that would be very inconsistent with
how collection/subcollection clearly distinguish exactly *when*
you need the name attribute. And I think, as often as possible,
an IMPLIED attribute should indicate an attribute that is *always*
optional, not a case where the user has to figure out for themselves
whether the context requires it.

An alternative fix is to add something like a <subcomposite-element>
tag .... but if I was a user I would be like "subcomposite-element????!!"
"what the hell is that?!" hmmmmmm....can't think of anything better
right now. Is there a better _name_ for it at least? Anyone?

How about adding:

<nested-composite-element name="foo" class="foo.Foo"/>

and renaming subcollection to:

<nested-collection role="bar"/>

Well, at least we've discovered a case for which the semantics are clear
but no test exists. Also I've been meaning to comment that dtd but just
hadn't
had a chance yet. I'll move _that_ to the top of the list....

[Hibernate-devel] subcollection v collection

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

<!ELEMENT composite-element ( (property|many-to-one|collection|composite-element)* )>
  <!ATTLIST composite-element class CDATA #REQUIRED>

  should be

<!ELEMENT composite-element ( (property|many-to-one|subcollection|composite-element)* )>
  <!ATTLIST composite-element class CDATA #REQUIRED>

?

Subcollections are not mentioned in the tutorial; I am assuming that
the difference between a collection and a subcollection is that a
collection has a name (which is the name of its property of the
containing class) whereas a subcollection is self-identified as it is
part of a collection. This is similar to the difference between a
component and a composite-element.

e

Re: [Hibernate-devel] 0.9.5 is out

[Gavin_King/Cirrus%<CI...@ci...>]

>I think I found an error in the tutorial, versions 0.9.5 and 0.9.4 (and
>perhaps previous versions, too).

>The example in the section Collections > one-to-many associations
>has an error:
>The third line reads
>    <one-to-many column="bar" class="com.illflow.Bar"/>
>but  the "one-to-many"-element has no "column"-attribute.
>So the line should read:
>    <one-to-many class="com.illflow.Bar"/>

You are absolutely right, of course. I fixed that in CVS and added an
explicit note in the text. Thanks.

[Hibernate-devel] MappingByReflection improvements

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

I've made a second release of MappingByReflection

Improvements...
- more complete array element support (very lightly tested)
- more javadoc
- lazy="true" is default for Set Map and List properties
- now reports inability to find UID in superclass chain

e

[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

Re: [Hibernate-devel] 0.9.5 is out

[Georg S. <ge...@gm...>]

Hi *!

I think I found an error in the tutorial, versions 0.9.5 and 0.9.4 (and 
perhaps previous versions, too).

The example in the section Collections > one-to-many associations
has an error:
The third line reads
    <one-to-many column="bar" class="com.illflow.Bar"/>
but  the "one-to-many"-element has no "column"-attribute.
So the line should read:
    <one-to-many class="com.illflow.Bar"/>

Georg

[Hibernate-devel] schema and mapping generation

[Ralf P. <pu...@gm...>]

Hi,

did you ever consider using xdoclet (http://sf.net/projects/xdoclet) for 
building mapping and schema files?

Ralf

Re: [Hibernate-devel] Re: Hibernate and HSQLDB (HypersonicSQL)

[Gavin_King/Cirrus%<CI...@ci...>]

>Grabbed the latest CVS tonight.  The schema generation is still
>producing errors but all FooBarTests completed without throwing any
>exceptions.  Guess I was lucky.

Nope, that was the expected behaviour. The released version 0.9.5 will
throw
errors during the initial drop phase (this is possible with any DB, if the
tables aren't there). After that the create table script should execute
without error. (yeah yeah, i know, we should _really_ disable the dropping
of constraints in HypersonicSQL......)

[Hibernate-devel] Re: Hibernate and HSQLDB (HypersonicSQL)

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

Hi all,

Grabbed the latest CVS tonight.  The schema generation is still 
producing errors but all FooBarTests completed without throwing any 
exceptions.  Guess I was lucky.

Errors during schema generation are being caused by the use of Alter 
Table with constraints. e.g. Error dropping with - alter table foos drop 
constraint foosFK0.  
Sorry am unable to contribute a solution at the moment.

Phillip B.

[Hibernate-devel] 0.9.5 is out

[Gavin_King/Cirrus%<CI...@ci...>]

Please check it out and let me know if theres any problems.

If not, I promise to start work on the databinding stuff immediately :)

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

[Gavin_King/Cirrus%<CI...@ci...>]

>> Im guessing that, when in doubt, assume association (ie. many-to-one)

>Ah, here is my original question. I think it used to be that an
>association was simply a property with a Persistent class as its type.
>Do I understand that you have replace this with a new element
>many-to-one? (I see the syntax in the dtd, but I don't want to assume
>too much about the semantics.)

Yes. many-to-one is used for associations now. I know - it was easier the
old way but this is clearer, more flexible and necessary now we ditched
Persistent.

Its all documented in the tutorial.aft in CVS now.

>> differentiating many-to-many vs composite-element follows exact same
rules
>> as many-to-one vs component. But we can only tell with arrays.

>OK. I haven't thought much about array contents. I will dig into this
>tonight (i.e., several hours from now... I have to go to my "real" job).

Hah! Hey I'm a real fan of not trying to do *everything* in one go. Release
what you have, when you're happy with it. It doesn't have to be finished to
be useful.

[Hibernate-devel] hibernate

[Gavin_King/Cirrus%<CI...@ci...>]

<P>&nbsp;<BR><BR><FONT SIZE=3D2><B>Fabricio Matheus Goncalves &lt;fmatheus@=
bigbross.com&gt;</B></FONT><BR><FONT SIZE=3D2>02/07/2002 12:53 PM ZW2</FONT=
><BR><BR> <FONT SIZE=3D2>To:</FONT> <FONT SIZE=3D2>gk...@ci...<=
/FONT><BR> <FONT SIZE=3D2>cc:</FONT> <BR> <FONT SIZE=3D2>bcc:</FONT> <BR> <=
FONT SIZE=3D2>Subject:</FONT> <FONT SIZE=3D2>hibernate</FONT><BR> <BR><BR><=
/P><P><FONT FACE=3D"Monospace,Courier">Hi,<BR></FONT><BR><FONT FACE=3D"Mono=
space,Courier">Im just playing with your project cvs tree.<BR>And I make a =
Ant build.xml to easy the build process, since i dont use<BR>ide (just emac=
s + ant).<BR>So i would like you could add this to cvs to help others.<BR>A=
ll this need to work is a diretory lib, with jar's your project need,<BR>if=
 that isnt in classpath yet.<BR>And ant: <A HREF=3Dhttp://jakarta.apache.or=
g/ant>http://jakarta.apache.org/ant</A><BR>I may help if you have any probl=
em.<BR></FONT><BR><FONT FACE=3D"Monospace,Courier">See ya, Fabricio.<BR></F=
ONT><BR><FONT FACE=3D"Monospace,Courier">PS: would be nice if you move all =
the docs from the root of the project<BR>to lets say a doc directory ;-)<BR=
></FONT><BR><BR></P>

Re: [Hibernate-devel] Comparison with Castor?

[Gavin_King/Cirrus%<CI...@ci...>]

Ah. I realise my reply was too focused upon the O/R thing, which is not all
Castor does. Also they support persistence to LDAP. And their databinding
isn't vapor. ;)

Re: [Hibernate-devel] Comparison with Castor?

[Gavin_King/Cirrus%<CI...@ci...>]

Hi Cuong :)

I feel somewhat uncomfortable answering this question since I havn't used
Castor myself. I _have_ spent a little bit of time the last couple of days
trying to make sense of their documentation (which is very bad) and
examples (which are virtually non-existent). So I'm not going to be able to
give a really definitive answer to this.

It _is_ clear that Hibernate + Castor have similar approaches in that they
share the following:

XML O/R mapping,
use of reflection,
diffing objects to determine which objects need updating,
support for optimistic locking,
OO query language

and even some of the API looks pretty similar.

On the other hand, it seems that the two projects differ in their emphasis
in at least these aspects:

architecture,
documentation,
supporting tools,

Architecture first: Hibernate is an as-thin-as-possible object/relational
persistence service. Many OR persistence layers end up implementing an
OODBMS that uses a relational database as a file system. I think Castor has
gone down this path of essentially having two databases; an OODB in RAM and
an RDB on the disk. This approach has the single advantage that it permits
cacheing in the persistence layer. It has the disadvantage of being
arguably less scalable and much less robust. Have a quick look at Castor's
changelog and check how many of their bugs are to do with concurrency
issues. Hibernate is essentially immune to concurrency bugs because its
critical code is single threaded! We let a mature relational database
handle concurrency because thats what they do well.

My understanding (this was stated explicitly in the Castor mailing list but
I can't find anything addressing the issue on their website) is that Castor
cannot operate in a cluster (or, presumably, when sharing access to the
database with other applications or JVMs).

Hibernate comes with about 25 pages of (growing) documentation of how to
actually use it, with (hopefully) clear explanation of the semantics of
various things. We also have an automatic table schema generation tool and
will soon have a map generation tool. Castor can't create tables for you,
you need to write SQL scripts by hand. To me, hibernate is more than about
providing a persistence mechanism, its about speeding up the development
process. This is, I think, a very essential difference. The project was
motivated by my frustration with low-productivity in J2EE environments, not
by my difficulty persisting objects :)

I wish someone who knows Castor would draw up a feature matrix comparing
the two projects. At the moment the only thing I noticed they are missing
is support for what we call "components" and the only things we are missing
are support for auto-increment columns + oracle sequences for key
generation. But I'm sure there are heaps of other things.

Components are actually a _really_ cool feature since they let you store a
whole graph of objects in a single row of a table. This lets you use a much
finer grained object model and still get acceptable database performance
(no need for a table join for each dependent object).

Actually another difference is they allow _associated_ objects to be
"lifecycle" objects, whereas we only allow components and collections as
lifecycle object. We will add this feature at some stage.

Hopefully in future I will be able to answer this question more accurately.

Gavin

[Hibernate-devel] MappingByReflection status

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

I completed the refactoring, breaking the one MappingByReflection
class into eight classes. I put them all in the tools.reflect package.
Maintenance should be easier that way.

The reliance on Persistent has been eliminated as suggested. Abstract
classes are allowed in the superclass chain. Tomorrow I plan to add in
the properties from transient superclasses, finish array handling,
eliminate duplicate table and column names, and clean up.

Are there any situations (short of naming heuristics or config files)
where you would expect the relection code to generate:
 many-to-one
 one-to-many
 many-to-many
 composite-element?
I just want to make sure I understand the dtd.

Your daily dose of XML is below.

e


usage: class.name | uid=<newUID> | done
? uid=code
niceKey(code): code uid UID id ID key KEY pk
? cirrus.hibernate.test.Baz
addClass(cirrus.hibernate.test.Baz)
? done
<hibernate-mapping>
<!-- cirrus.hibernate.test.Baz root -->
 <class name="cirrus.hibernate.test.Baz" table="Baz" select="distinct">
    <id name="code" type="java.lang.String">
      <column name="code" length="16"/>
      <generator class="hilo.hex"/>
    </id>
    <!-- array name="setArray" type="[Ljava.util.Set;" -->
    <!-- DUNNO: array of set name="setArray" type="java.util.Set" -->
    <array role="setArray" table="setArray">
      <key column="uid"/>
      <index column="idx"/>
      <element column="elm" type ="java.util.Set"/>
    </array>
    <!-- list name="setList" type="java.util.List" -->
    <list role="setList" table="setList">
      <key column="uid"/>
      <index column="i"/>
      <element column="elm/>
    </list>
    <!-- map name="stringDateMap" type="java.util.Map" -->
    <map role="stringDateMap" table="stringDateMap">
      <key column="uid"/>
      <index column="key" type ="java.lang.String"/>
      <element column="elm/>
    </map>
    <!-- set name="stringSet" type="java.util.Set" -->
    <set role="stringSet" table="stringSet">
      <key column="uid"/>
      <element column="elm" type ="java.lang.String"/>
    </set>
    <!-- array name="fooArray" type="[Lcirrus.hibernate.test.Foo;" -->
    <!-- association name="cirrus.hibernate.test.Foo" type="cirrus.hibernate.test.Foo" -->
    <property name="cirrus.hibernate.test.Foo" column="cirrus.hibernate.test.Foo" type="cirrus.hibernate.test.Foo"/>
    <!-- array name="components" type="[Lcirrus.hibernate.test.FooComponent;" -->
    <!-- TO DO: array of component name="components" type="cirrus.hibernate.test.FooComponent" -->
    <!-- set name="fooSet" type="java.util.Set" -->
    <set role="fooSet" table="fooSet">
      <key column="uid"/>
      <element column="elm" type ="java.lang.String"/>
    </set>
    <!-- list name="customs" type="java.util.List" -->
    <list role="customs" table="customs">
      <key column="uid"/>
      <index column="i"/>
      <element column="elm/>
    </list>
    <!-- map name="stringArrayMap" type="java.util.Map" -->
    <map role="stringArrayMap" table="stringArrayMap">
      <key column="uid"/>
      <index column="key" type ="java.lang.String"/>
      <element column="elm/>
    </map>
    <!-- array name="stringArray" type="[Ljava.lang.String;" -->
    <!-- array of basic name="stringArray" type="java.lang.String" -->
    <array role="stringArray" table="stringArray">
      <key column="uid"/>
      <index column="idx"/>
      <element column="elm" type ="java.lang.String"/>
    </array>
    <!-- list name="stringList" type="java.util.List" -->
    <list role="stringList" table="stringList">
      <key column="uid"/>
      <index column="i"/>
      <element column="elm/>
    </list>
    <!-- array name="intArray" type="[I" -->
    <!-- array of basic name="intArray" type="int" -->
    <primitive-array role="intArray" table="intArray">
      <key column="uid"/>
      <index column="idx"/>
      <element column="elm" type ="int"/>
    </primitive-array>
 </class>
</hibernate-mapping>

[Hibernate-devel] Tools (Re: MappingByReflection Re: Recent Changes and 0.9.5)

[Gavin_King/Cirrus%<CI...@ci...>]

Paul Szego wrote:
> At the risk of over-comlicating what should be a simple task - could we
> use some kind of *simple* config file in addition to the command line
> settings (perhaps at a later stage when it's more stable)?

[snip]

> But in this area I think it would be good to perhaps stretch this a
> little to maintain what I think is a really good design goal - you just
> point the tool at the code and *most* of the time "magic happens" and
> you've got persistence. And when you do something outside what the
> USB-attached-crystal-ball can cope with it's not traumatic to figure out
> how to deal with it.

> So maybe setting up some simple config options that are exceptions to
> the rules (like ID attribute names or sub-tree roots that we want to
> force into separate tables) life for the developer throughout the
> development cycle is still painless. Make code changes, run "ant all"
> and fire up my app each time I change something.

Yeah I think we do want the tool to be reasonably easily customizable to
developer preferences but I dont think we should actually include stuff
like "sub-tree roots that we want to force into separate tables". If we
include stuff like that then the logical extreme is that we end up with a
tool that basically takes its _own_ mapping document and spits out the
XML style mapping. My feeling is thats just too much stuff to keep track
of. There should be the Java classes and the XML mappings and tools should
work with those and with user input.

As far as the cmd line tool that Doug is working on now goes, I don't
envisage that the user would be running it more than once for a particular
hierarchy of classes. It "gets you going" - it does 70% of the work and
then leaves you to fill in the gaps (and maintain the mapping as your
codebase evolves) by hand. Later on we might provide extensions to the
tool that _help_ you fill in the gaps.

Eventually what I think we should aim for is a GUI tool that can back-parse
the auto-generated (or hand-coded) mapping and allow visual manipulation.

Gavin

[Hibernate-devel] Comparison with Castor?

[Cuong T. <ct...@ya...>]

Hi everyone,
  I saw this project on TSS and am very interested.  Before I dig any further, 
could someone give a brief comparison between hibernate and castor?

Thanks.

=====
Cuong Q. Tran <ct...@ya...>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

Re: MappingByReflection Re: [Hibernate-devel] Recent Changes and 0.9.5

[Paul S. <pau...@ne...>]

My 2cents worth below. PaulS :)

Doug Currie wrote:
> Wednesday, February 06, 2002, 3:28:06 AM, Gavin wrote:
> 
>>>Yes. I currently use Persistent in two ways.
>>>
>>>1. When computing the inheritance graph. As classes are added to the
>>>set to be analyzed, I construct this graph (well, actually a set of
>>>trees since Java is single inheritance). The lack of a Peristent
>>>interface tells me when to stop climbing superclass links to insure
>>>that all requisite classes are included
>>>
> 
>>I take it you mean you stop climbing the tree looking for _classes_.
>>Properties from superclasses _should_ be included....
>>
> 
> Ah. I did misunderstand this. I assumed properties of non-Persistent
> classes were transient. I will fix it.
> 
> <snip>
> 
>>Another suggestion:
>>
> 
>>One possible hueristic that "solves" both problems is to see if something
>>there looks like an ID property. If theres none, its a component or a
>>non-persistent superclass. A command line switch could even set a list of
>>property names the user uses for IDs.

At the risk of over-comlicating what should be a simple task - could we 
use some kind of *simple* config file in addition to the command line 
settings (perhaps at a later stage when it's more stable)?

One of the reasons that I like Hibernate so far is that it fits with my 
philosophy of toolset / framework design: simple things are easy, 
complex stuff is possible (to whatever degree the tool decides to 
comlicate itself).

A lot of the discussion so far seems to go with this: wherever possible 
use reasonable defaults or make some reasonable assumptions about how 
people are going to write their code (e.g. they're always going to use 
the same attribute name for an ID attribute).

But in this area I think it would be good to perhaps stretch this a 
little to maintain what I think is a really good design goal - you just 
point the tool at the code and *most* of the time "magic happens" and 
you've got persistence. And when you do something outside what the 
USB-attached-crystal-ball can cope with it's not traumatic to figure out 
  how to deal with it.

So maybe setting up some simple config options that are exceptions to 
the rules (like ID attribute names or sub-tree roots that we want to 
force into separate tables) life for the developer throughout the 
development cycle is still painless. Make code changes, run "ant all" 
and fire up my app each time I change something.

> 
>>I kind of like this solution because it isolates as much possible
>>dodgy guessfulness in one single rule that the user can understand and
>>control, rather than having ten different rules that interact in wierd
>>and unpredictable ways.
>>
> 
> I like it, too, especially for climbing the superclass chain, since
> there is exactly one ID at its root that they all share. So, the user
> can specify a class and an ID property (and optionally a generator)
> and this completely specifies (a path through) the tree.
> 
> If the user wants multiple subclasses from different paths in the same
> table, a list of fringe subclasses could be specified with one ID
> property. For example, using the notation X[Y,Z] where X is a direct
> superclass of Y and Z, in A[B[C],D[E]] with A's ID specified...
> 
> listing classes     yields table
> ---------------     ------------
> B                   A{B}
> E                   A{D{E}}
> C,D                 A{B{C},D}
> 
> I suppose it's possible to specify a different list of subclasses and
> get another table with the same or different root class. For example,
> for class E with D's ID, you'd get table D{E}.
> 
> Now, I believe the rule is one table per class.
> So this combination is legal:    A{B} and D{E}
> but this combination is illegal: A{B} and A{D{E}}.
> Right?
> 
> The current implementation would yield A{B,D{E}} in either case. But
> if we add the extra ID argument, separate A{B} and D{E} tables becomes
> possible.
> 
> As far as using IDs for choosing between association and component, I
> am not as happy, but at least it is something.
> 

You could achieve the same by only specifying the exceptions to the 
rule, i.e. the roots of the *sub* trees. In this case D.

> 
>>>Currently the following must be true of a class before it is added as
>>>a persistent [super]class:
>>>the class
>>>C1. is not Primitive
>>>C2. is not an Array
>>>C3. is not an Interface
>>>C4. is not nested (an inner class), i.e., c.getDeclaringClass() == null
>>>C5. is not Abstract
>>>C6. has a public default constructor (0 arguments)
>>>C7. implements Persistent
>>>
> 
>>C3 I _guess_ is reasonable, though not essential.
>>
> 
> I don't think Interfaces can have properties unless they're
> implemented in the concrete class. The real purpose of this rule is to
> prevent command line specified Interfaces from appearing in the table.
> The code would never find an Interface in the superclass chain.> 
 >
>> C5 I dont think is right.
>>
> 
> OK, I can easily remove it. What happens if the user tries to
> instantiate an abstract class, e.g., with a query?
> 
> 
>>C6 is changed to: it has a default constructor of any visibility level.
>>
> 
> OK. But perhaps a warning is in order (?) since private 0-arg
> constructors usually signal non-instantiable classes.

I disagree.

>>From Java Lang Spec 2nd edition:
> If the intent is simply to prevent instantiation of a class, the
> proper way to express this is to declare a constructor (§8.8.8) of no
> arguments, make it private, never invoke it, and declare no other
> constructors. A class of this form usually contains class methods and
> variables. The class Math is an example of a class that cannot be
> instantiated

The key phrase being "and declare no other constructors". It's common to 
NOT have a default constructor so that objects are forced into a "valid" 
state (from a business rule perspective) at creation. Sometimes a static 
helper method is used if this is complex, but that's *mostly* a hangover 
from C++ days when throwing exceptions in constructors was problematic.

>>>Determining property roles is much more difficult. Currently I am
>>>using the following heuristic
>>>
> <snip>
> 
>>Nothing should default to Serializable. Its almost always a bad idea to
>>store things in serialized form. (Unless they are, genuinely a stream
>>of bytes. eg. a JPEG or something.)
>>
> 
> Agreed. I was lazy (Serializable is easy to determine,
> component-izable isn't). I will fix the code.
> 
> An administrative question for Gavin:
> 
> Currently the MappingByReflection is implemented in a single Class
> with several nested classes. Before tackling the above changes I
> should probably refactor the code into a few top level classes; this
> will facilitate its use by the eventual GUI tool and make maintenence
> easier, I think. Can I claim package cirrus.hibernate.tools.reflect or
> would you prefer it somewhere else?
> 
> e
> 
> 
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> 
> 
> 

Re[2]: MappingByReflection Re: [Hibernate-devel] Recent Changes and 0.9.5

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

> Perhaps we could use a similar approach to Beans introspection here -
> guess based on what methods exist. In beans you have a convention for 
> naming indexed properties, there might be a broad enough generalisation 
> we could apply here ourselves for guessing what's in a collection.

I like this. I had considered peeking into the .class file to see how
the result of getXXX was cast, but quickly came to my senses.

e