hibernate-devel — development

[Hibernate-devel] Property naming

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

Hi,

just one observation regardning "property" names. I believe that 
property names begin with a lowercase letter, and only appear with a 
leading letter capitalized when appended to other things (e.g. in the 
name of a get method).

But in several places, e.g. the mapping XML file and the query language, 
it seems that properties are specified with a leading capital letter.

This is only minor, but would be inconsistent with any Beans code that 
relied on stricter naming conventions.

PaulS.

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

[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

[Hibernate-devel] Mapping tool

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

Hi,

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.

PaulS :)

[Hibernate-devel] Doco

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

Hi all,

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

Regards, PaulS :)

[Hibernate-devel] Design question

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

Just a couple of questions about design decisions, if I may.

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.

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.

Regards, PaulS :)

[Hibernate-devel] Is this list alive?

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

Hi,

There doesn't seem to be much activity in the SourceForge forums, is 
this the place to discuss Hibernate? Or are there other forums somewhere?

Regards, PaulS :)

Re: [Hibernate-devel] Re: Hibernate

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

Okay. I've "finished" the refactoring of the map package in the sense that
its now a much better OO model of things like Tables, Columns, Classes,
Properties, Collections, etc. In the process I even fixed a bug I didn't
know was there ;)

It was a _lot_ harder than I expected. (And would have been even harder
without the test suite.)

The downside is (1) its _still_ not the most elegant code ever written but
hopefully that can evolve without any more major rewrites (2) I completely
broke the schema generation.

Since we needed a total new approach to schema generation anyway, I'm going
to check the new code into CVS under the HEAD branch. The STABLE branch
will still have the current version 0.9.4. Feel free to do any work on the
STABLE branch and I will merge it later.

Daniel and I will work on the HEAD branch and hopefully have schema
generation up and running again very soon. If anyone wants to help out with
this, please let me know.

PS. We've had a lot of traffic coming from theserverside.com and I'm
continuing to get mail from people who are playing with and really liking
the system. :)
PPS. Sourceforge's download metering is broken so just ignore the bit about
zero downloads since 4 days ago - its very wrong.

[Hibernate-devel] Re: Hibernate

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

>- Automated tests

>Yes they are great ... for things that can be tested. But when you start
>talking about developing GUI tools for Hibernate. How do you test those
>automatically? It's really hard. I'm not saying lets not test them, but
>we need to think about it if we are going to write the tests alongside
>the actual code, as I want to get started quite soon on some of this.

Yeah thats an entirely sane comment. I must admit I wasn't thinking so
clearly about the toolset part of the project. For the engine the tests
are _essential_....but automated tests of GUIs are arguably wrongheaded
(A good test should encode a functional _requirement_, not a temporary
decision about how user input is gathered.)

I can think of two responses:

1. The correctness of the development tools is not really as critical,
and anyway not as clearly defined ... so lets not bother with tests
(Tests _can_ be a maintenence nightmare)

2. Perhaps its useful to expose a _programmatic_ interface to the tools
which the GUI and tests and commandline client and possibly other frontends
or applications use. I'm not at all convinced of the usefulness of this -
its just a suggestion.

Anyways. I think its clear we dont need to be too strict about requiring
tests for the toolset. cool :)

>I have seen a project that had automated tests that required the user to
>simply go a view some output. Ok, not very automated, but as good as it
>gets maybe?

Yeah I'm quite happy with that myself. I always think you get 80% of the
test effectiveness without _any_ assertions....just the test running is
already a big thing.

On the other hand, I think that for the persistence _engine_, we will
always
know extremely clearly the semantics we are trying to implement ... and we
will know that those semantics (and the interface) can't change without
breaking client applications. So the tests shouldn't be a maintenence prob.

Okay anyways lets not get too bogged down in discussions of methodology.
Everyone has strong opinions and usually what happens is that things
decided
a priori are totally irrelevant since what actually gets _followed_ is what
the developers doing all the work are comfortable with. I'd rather see
good code developed haphazardly than bad code done the "right way (tm)".

However, it is a major aim of this project to generate pages and pages of
quality documentation. Its such a missing aspect in soooo many other open
source projects.

>- Grouping, sum, count etc?

>Just a thought. I actually needed to find out how many objects existed
>(or how many rows in the table to put it crudely). I ended up just doing
>a .size() on the collection results. Is there a better way? Do any other
>OO query langs allow this sort of thing?

Such things would be _ace_. At present though, the query language only
returns
persistent objects, never properties and its not clear what the sum of a
set of Customers would be :) From my brief survey .... somebody please
correct me if I'm wrong on this ... i think OQL is the only OO query
language
that has aggregate functions. The Hibernate query language is very much a
work in progress (infancy?).

>- Visual mapping (cocoabase)
>In theory, it could really be powerful. Imagine JBuilder and WSAD
>plugins as well!

yeah thats what I was touching on with the GUI mapping generator.
The one tool like that I ever used (VAJ's map+schema browsers) sucked
horribly but its gotta be _possible_ to do something good.

An eclipse plugin would be very very nice!

>- MS SQL server and Informix

I betcha SQL server works immediately by using the SybaseDialect.

[Hibernate-devel] Re: Hibernate

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

That was quite a large email and after reading a few times have 
extracted what I think is important and want to discuss more. I 
encourage everyone else to do the same.

- Automated tests

Yes they are great ... for things that can be tested. But when you start 
talking about developing GUI tools for Hibernate. How do you test those 
automatically? It's really hard. I'm not saying lets not test them, but 
we need to think about it if we are going to write the tests alongside 
the actual code, as I want to get started quite soon on some of this.

I have seen a project that had automated tests that required the user to 
simply go a view some output. Ok, not very automated, but as good as it 
gets maybe?

- Grouping, sum, count etc?

Just a thought. I actually needed to find out how many objects existed 
(or how many rows in the table to put it crudely). I ended up just doing 
a .size() on the collection results. Is there a better way? Do any other 
OO query langs allow this sort of thing?

- XML data binding

Had a quick talk to Gavin today about this one and I think we both agree 
it's a feature that really needs to be done soon. I think a default 
mapping would be fine to get in there just so it's listed as a feature 
and attracts more ppl to the project. Although Gavin did mention custom 
mappings (and some crazy XSL template inheritence .. what an OO purist). 
I think getting a default mapping out soon would be great!

- Visual mapping (cocoabase)

Any other ppl used these tools? I used Cocoabase once and I seem to 
remember some sort of visual mapping tool. It had potential, but didn't 
really happen. I think something really funky/nice could be done for 
this. In theory, it could really be powerful. Imagine JBuilder and WSAD 
plugins as well!

- MS SQL server and Informix

Indeed! I can get some evaluation versions of these two databases for 
the weekend and have a play. Who knows .. I might even have a dialect by 
next week. Anyone else got immediate access to these products? Get testing!

I've recently been using Hibernate in a small web project to see how 
well it stands up to it's claims of making your development cycle 
smaller/faster etc. And well, it certaintly has!

I hope we can get a bit of activity in this project and more people 
hammering out code.

Daniel

[Hibernate-devel] Hibernate

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

Okay...

Thanks everyone for your offers of help. We should do this by mailing list,
I guess, so could everyone join the hibernate-devel mailing list here:

https://sourceforge.net/mail/?group_id=40712

and let me know your sourceforge usernames so I can give CVS access.

My priorities (which need not be yours, of course) for the next phase of
the project are:

New Features
============
1. XML Databinding
2. Extensions to Query Language
3. command line or GUI toolset for (a) generation and execution of table
schema (b) automated generation of skeletal XML mappings

Refactorings
============
1. The map package
2. The query package

The project has so far been executed very much along XP philosophy of
making things work first and then trying to make the code elegant. This has
worked quite well but right now the next new functionality will depend upon
first refactoring some existing design that has been pushed past its
limits.

The cirrus.hibernate.map package is a mess that is doing far more than it
was originally intended for and the schema generation tools and XML
databinding will depend upon it. I am in the process of refactoring it now
but I cant check anything into CVS quite yet.

The cirrus.hibernate.query package was written by some idiot (me) who had
no idea about parsers + lexers at the time. (On the other hand, it
successfully implements a pretty decent OO query language.) Anyways, I know
a whole lot more now and want to reimplement the query functionality using
an ANTLR grammar. I've got the ANTLR grammar sitting in CVS as
Hibernate/hql.g but if you compile that file with ANTLR it essentially
implements echo. A very high priority is to make it implement an
object-oriented-query-language-to-SQL translator! This should not be as
difficult as it sounds because as a first step we can reuse some old code,
particularly cirrus.hibernate.query.Query. If anyone wants to take on this
job that would be _brilliant_. The query language has the potential to be
one of the best features of the project and I can think of a few really
great extensions that would not even take that much work.

We need to have some discussions about the best approach to the databinding
stuff - but lets leave that for later.

The existing table-schema-generator is an un-object-oriented, ad hoc tool
that I described as "experimental" in the documentation - meaning it sucks.
You might have already noticed that for complicated schemas like in the
test suite it can't even drop its own tables on some databases! I'm
guessing that what users really need is a commandline or GUI tool. When
I've finished my refactorings to the map package (which will include a
proper OO model of relational database tables), that should be easier to
build. I think Daniel has already signed on for that.

The other tool I'd love to see is a GUI that lets the user map classes and
properties of classes (discovered by relection) to database tables and
columns _visually_ and spits out XML mappings. A first step towards this
would be a simple commandline tool that generates a skeleton mapping given
the name of a class.

--------------------------------------------------------------------------
phew.

What ideas do _you_ guys have?

--------------------------------------------------------------------------

There are two coding standards:
1. Write automated tests.
2. Write user documentation.

True, they arent coding standards.

Basically, no bugfix should ever be checked into CVS without a
corresponding test. No new feature is finished without automated tests and
updates to the documentation. Whenever I've strayed from fanatical
adherence to these rules I've regretted it.

To make writing documentation easy, I've been using AFT.

For tests, I'm not using JUnit because I wanted users to be able to run the
tests without downloading it. Also I think JUnits a bit bloated. If you
guys love JUnit and think I'm trippin, we'll use JUnit.

For XML processing, I havn't been using JDOM, for the same "not wanting to
force people to download too much extra stuff" reason. But I'm a lot less
comfortable with this decision, since JDOM code is _so_ much prettier and
more maintainable. What does averyone else think?

---------------------------------------------------------------------------
Current target platforms are:

Working Now:
============
DB2
MySQL
PostgreSQL
Oracle
Sybase
Interbase

Just Got Emailed Support For:
=============================
McKoi

Really Want To Support But Don't Have Installer For:
====================================================
MS SQL Server <-- top priority
Ingres
Informix

Be Nice:
========
HypersonicSQL
InstantDB
---------------------------------------------------------------------------
That should be more than enough to keep us busy :)

Peace

Gavin