hibernate-devel

[Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

Future plans:

Next release: 1.2.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* various bugfixes
* full support for Clob and Blob
* FlushMode API + deprecation of suspend/resumeFlushes
* Improved logging of bind variables, etc.

1.2.1 is almost ready to go. Should be released in one=20
to two weeks. This will be a very stable platform for=20
development and we should continue to fix any bugs in=20
the 1.2 branch concurrently with 2.0 development.

Hibernate 2.0 beta
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* create a new module in CVS with improved directory=20
  structure
* rename packages to net.sf.hibernate
* replace existing configuration mechanisms=20
  with an interface that unifies the functionality
  of HibernateService, (the misnamed) Datastore,
  Hibernate.configure() and Configuration.
* query language enhancements, starting with:
  - OUTER JOIN, FULL JOIN, etc
  - AS instead of IN, IN CLASS
  - select new Foo(bar.name, bar.count) from .....
* JCA implementation
* removal of support for toplevel collections /
  subcollections

That list of features (for 2.0) should be considered a=20
proposal. If anyone thinks there are more urgent things
than those listed (ie. more urgent for the user base as
a whole, rather than for themseleves personally), we can
vote on it.

Something I would like everyone to consider and vote on=20
at this stage is:

Should 2.0 be 100% backward compatible with 1.2?

Because almost everything is defined by interfaces (and=20
because I don't envisage any change in semantics for
any operations of the core interfaces), we *could*=20
continue  to support the existing interfaces alongside=20
the "new" net.sf.hibernate.* interfaces.

However, I am quite keen to actually rip out a lot of code
relating to support for toplevel collections and the various
old configuration mechanisms.

I see three possibilities here:
(1) make a clean break - most applications will be portable
    to 1.2 with nothing more than a few simple text search/
    replace (s/cirrus.hibernate/net.sf.hibernate). This will
    mean less code to manage / distribute.
(2) continue to support certain core interfaces:
    - Session
    - SessionFactory
    - UserType
    - Hibernate
    - Query
    - ScrollableResults
    - ???
(3) Full backward compatibility

Lets discuss / vote on this now, even though we won't be=20
starting work on 2.0 for a few weeks now. People voting for
(3) will be assumed to be volunteering for some of the=20
extra work involved in implementing / maintaining this ;)

I suspect that many people would be tempted to vote for (2).
But is there really *that* much value in that for the users?
The interfaces themselves arent changing, so its a simple
search/replace followed be recompile.

peace

Gavin



********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 21 Dec (11:15), Gavin King wrote:

> I suspect that many people would be tempted to vote for (2).
> But is there really *that* much value in that for the users?
> The interfaces themselves arent changing, so its a simple
> search/replace followed be recompile.

Maybe this recommendation is a bit unpopular: 

Get rid of the name "Session"! I spent the last three days implementing
lazy loading in a clean separated Three-Tier-Architecture and it's
driving me crazy. Whenever I read the documentation, I also had this 100
milliseconds think time when I hit the word "Session" or "Transaction"
until I realized that the statement was about the Hibernate thing, not
about the _concepts_...

Well, I have to manage two layers of Session Beans (stateful and
stateless), a HttpSession containing a UserSession and some other stuff
named similar. My code is clean, but the next developer looking at this
stuff will have a hard time understanding why there's another "Session"
in the Persistence Layer that uses UserSession to store its disconnected
state and gets this one from the SessionContext of the stateless
SessionBean Business Facade. And this was only have the system up from
the bottom, there are some other "Sessions" in the top layer.

Ok, it's not that serious, but I feel alot better already ;)

-- 
Christian Bauer
tu...@in...

Re: [Hibernate] Road Map

[Mark W. <mor...@SM...>]

Gavin King wrote:

>Future plans:
>
>Next release: 1.2.1
>===================
>* various bugfixes
>* full support for Clob and Blob
>

How are you planning on supporting this?  Is there going to be some 
internal changes in Hibernate to support them, or are you just going to 
add new Blob and Clob types?


>I see three possibilities here:
>(1) make a clean break - most applications will be portable
>    to 1.2 with nothing more than a few simple text search/
>    replace (s/cirrus.hibernate/net.sf.hibernate). This will
>    mean less code to manage / distribute.
>  
>

+1


-Mark

Re: [Hibernate] Road Map

[Max R. A. <ma...@eo...>]

>Hibernate 2.0 beta
>==================
>* create a new module in CVS with improved directory
>  structure

Yes! :)

> * rename packages to net.sf.hibernate

Yes! :)

>* replace existing configuration mechanisms
>  with an interface that unifies the functionality
>  of HibernateService, (the misnamed) Datastore,
>  Hibernate.configure() and Configuration.

Kewl - but not a big thing in my book...but it might be for purists :)

>* query language enhancements, starting with:
>  - OUTER JOIN, FULL JOIN, etc
>  - AS instead of IN, IN CLASS

I've been thinking about this outer join thingy - and I hope it is one of
the first thing
we can get implemented. I tried last night, but I do not have enough
knowledge regarding the parser
to do it in due time. The reason I like to have it is that OUTER JOIN's in
the query language is
very important for many applications, and that I can't find a workaround to
this problem (except issuing two or more queries).
....

>  - select new Foo(bar.name, bar.count) from .....

This one is going to be fuun :) (You didn't follow up on the discussion on
identity for these "value beans" - was it just to insane or ? :)

>* JCA implementation

Let's make this one as clean and simple as possible - no magic :)

>* removal of support for toplevel collections /
>  subcollections

Fine by me :)

>Should 2.0 be 100% backward compatible with 1.2?

Not necessarily :)

>Because almost everything is defined by interfaces (and
>because I don't envisage any change in semantics for
>any operations of the core interfaces), we *could*
>continue  to support the existing interfaces alongside
>the "new" net.sf.hibernate.* interfaces.

I see no reason why we should keep around the old cirrus.hibernate package
name....

I see three possibilities here:
(1) make a clean break - most applications will be portable
    to 1.2 with nothing more than a few simple text search/
    replace (s/cirrus.hibernate/net.sf.hibernate). This will
    mean less code to manage / distribute.
(2) continue to support certain core interfaces:
    - Session
    - SessionFactory
    - UserType
    - Hibernate
    - Query
    - ScrollableResults
    - ???

What is the difference between 1 and 2 ?
Are you going to change core names like Query, or is it the actual methods
on the interface you are going to change ?
Or is option 2 just about keeping the old cirrus.hibernate prefix for those
interfaces ?

Im at least +1 for (1)...

Another suggestion for Hibernate 1.2 is to look into adding support for
RowSet's - or at least provide enough information from the result of an
query to implement an RowSet efficently. I think RowSet is much better,
simpler and richer than just returning Collection of Object[]  ....(and I
now the "new Foo(name, otherstuff)" will help here - but still :)

That was my 2 cents :)

/max