Re: [Hibernate-devel] Design question

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

>The first is about needing a *public* default constructor. In other
>places hibernate will access non-public methods (e.g. property get/set
>methods), so I was wondering if it was a concious decision NOT to do the
>same for the default constructor of a presistent capable class.

 Thats a wrinkle I guess. If you want to iron it, go ahead.


>The other is the "marker" interface Persistent. I'm aware of reasons why
>you would / wouldn't want it, but wanted to hear from the team why it
>was chosen to go this way with Hibernate.

 I think its worth deprecating Persistent. What I initially took to be a
 feature is probably misfeature and, even if it isn't, it probably looks
 that way to users. Hibernate doesn't really use it for anything other than
 typesafeness and guessing Types at config time. At some stage we should
 deprecate it and do a r/Persistent/Object/g. Its not a huge job.

 The original reason for its existence was that it actually declared two
 methods ( getID()/setID() ). After they were no longer necessary, I still
 thought it was a good idea to have it as a marker interface. My reasoning
 was it indicates to users of the persistent class that the class is
 persistable, and that certain extraneous-looking methods like version and
 id get/set pairs _are_ actually necessary. Also it adds typesafeness both
 for clients of the Session and for hibernate's internal implementation. If
 we ditch it we are going to have a codebase with an awful lot of methods
 that take Object.

 On the negative side, it is an extra unnecessary intrusion upon the model
 so all things considered it was probably a bad idea. A couple of people
 already commented negatively about it.

 Any volunteers?


>the doco is a little sparse, to say the least. Any plans to update it?

 The users guide is currently about 20 pages when printed but it would be
 better if it were about 5-10 pages of "getting started" type stuff and
then
 a seperate 50ish page doc explaining the full semantics and "advanced"
 features.

 Also we need much better (more?) example code. And then the doco could
 refer to the example application rather than to Foo and Bar ;)


>Need a volunteer?

 Absolutely!! Clearly its better if someone less familiar with the design
 decisions works on the doco.


>I've just migrated a utility to help produce the mapping spec (that I
>originally wrote for a different open source OR tool ;). It takes info
>from JavaDoc tags embedded in the source, and spits out a fair attempt
>at a mapping spec. I've written it as a Doclet, and it runs under JavaDoc.
>If anyone else might find this useful I'd be happy to plonk it somewhere
>public.

 Interesting. I've wanted a good way to configure Hibernate for people who
 dont like to mess around with external config files which are _always_ a
 hassle during deployment to appservers and suchlike...

 I had been thinking along the lines of a Java mapping API but to be honest
 the mapping model is complex enough that it would be quite difficult to
 make a user-friendly API.

 A javadoc-based solution requires source-processing but since you need to
 do it iff you change the persistent representation, thats quite
acceptable.

 We should give this some further thought and have a look at what Paul's
got
 there.

 Gavin