hibernate-devel

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

Re: [Hibernate-devel] Design question

[Daniel B. <db...@bi...>]

>
>
>I think its worth deprecating Persistent. What I initially took to be a ....
>
>The original reason for its existence was that it actually declared two ...
>If we ditch it we are going to have a codebase with an awful lot of methods
> that take Object.
>
Hmmmm why does that make me feel uncomfortable. Was that you in 
theserverside.com not long ago telling someone how easy it is to 
implement serializable?

>
> 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.
>
It doesn't force you to actually implement anything AND thanks to being 
able to implement multiple interfaces, it doesn't get in the road of any 
business model.

>>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.
>>
Sounds great Paul! I've always wanted to play with Doclets and I've 
never actually seen anything useful done with them. I was thinking this 
was a good way to keep information about the classes together, but then 
I am thinking that this seperation is part of what Hibernate is about. 
Seperating your clean/pure OO business model from the OO dirty 
relational model ;)

Either way. Great thing to be able to add to a feature list. Allowing 
ppl to configure via handed coded XML, plain GUI, IDE plugins AND from 
source parsing. Can anyone complain?

Daniel

Re: [Hibernate-devel] Design question

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

Daniel Bradby wrote:
>>
>> 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.
>>
> It doesn't force you to actually implement anything AND thanks to being 
> able to implement multiple interfaces, it doesn't get in the road of any 
> business model.

It's a pain for me, and I can think of a few reasons why it might be 
undesirable:

* adding persistence to existing code (PITA factor)
* polluting "business" classes with persistence details (purist whinge)

I use a "solution neutral" data management "layer" that allows me to use 
different persistence solutions, e.g. TOPLink or Hibernate or whatever. 
Having visibility to hibernate classes (or TOPLink or whatever) isn't a 
great idea in this situation.

I know it's not a huge deal, since the interface is empty, but if 
there's no *need* for it I'd personally like to remove it.

Some approaches advocate using it so they can tell what should be 
persisted, e.g. for "persistence by reachability". But since we have the 
mapping spec to tell us that I don't see the need.

> Sounds great Paul! I've always wanted to play with Doclets and I've 
> never actually seen anything useful done with them. I was thinking this 
> was a good way to keep information about the classes together, but then 
> I am thinking that this seperation is part of what Hibernate is about. 
> Seperating your clean/pure OO business model from the OO dirty 
> relational model ;)
> 
> Either way. Great thing to be able to add to a feature list. Allowing 
> ppl to configure via handed coded XML, plain GUI, IDE plugins AND from 
> source parsing. Can anyone complain?

I'll get the source in order and plonk it somewhere in the next couple 
of days. It's only basic (i.e. it does what I needed for now), but 
rather than try to guess what should be in a more complete version I'll 
show whats there and get some feedback.

Regards, PaulS :)

[Hibernate-devel] dialect setting

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

I caught up with the HEAD stream today, and tried the
NetworkInteractive example to see if it generated the sql for table
creation. I found that it needed a System property for the driver,
which is different from the old behavior. To repair this I made
changes in cirrus.hibernate.Environment and
cirrus.hibernate.impl.RelationalDatastore.

In Environment I added a new version of dialect() and the cache code:

        private static Dialect dialectCache = null;
        
        public static Dialect dialect() throws HibernateException {
                if( dialectCache != null ) return dialectCache;
                try {
                        dialectCache = (Dialect) Class.forName( System.getProperty(DIALECT) ).newInstance();
                        return dialectCache;
                }
                catch (Exception e) {
                        throw new HibernateException("The dialect was not set, or did not exist");
                }
        }
        
        public static Dialect dialect(Properties connectionProps) throws HibernateException {
                if( dialectCache != null ) return dialectCache;
                try {
                        dialectCache = (Dialect) Class.forName( connectionProps.getProperty(DIALECT) ).newInstance();
                        return dialectCache;
                }
                catch (Exception e) {
                        return dialect();
                }
        }
        

In RelationalDatastore I modified two methods (including changing the
signature for generateSchema...

        public SessionFactory buildSessionFactory(Properties connectionProps) throws HibernateException {
                generateSchema(Environment.dialect(connectionProps));
                Query.clearCache(); //ByIDQuery.clearCache();
                return new RelationalDatabaseSessionFactory(this, connectionProps);
        }

        public void generateSchema(Dialect dialect) throws HibernateException {
                //Dialect dialect = Environment.dialect();
                ...
        }

Now I can run the NetworkInteractive example as before. It prints the
create statements for the tables. It would be nice if it also provided
the statements to create the necessary unique ID table(s).

e