whoops - forgot to correct the reply address.... so here it goes again :)
----- Original Message -----
From: "Max Rydahl Andersen" <[EMAIL PROTECTED]>
To: "Gavin King" <[EMAIL PROTECTED]>
Sent: Sunday, December 22, 2002 6:24 PM
Subject: Re: [Hibernate] Road Map
> >>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 ? :)
>
> >I think we need to maintain a strict distinction between "value types"
> >and "entity types". These value beans shouldn't have any notion of
> >identity because they are of value type.
>
> I agree this will be the most often used scenario.
>
> >Besides, you can probably do almost everything you need by simply
> >using a "select distinct".
>
> Probably yes, but not if I have more than one column selected.
> e.g. select distinct new LightPatient(p.id, p.name, p.lastname, p.city),
new
> Doctor(d.accountid, d.name, d.speciality, d.address) from ....
>
> Here the LightPatient's will probably be unique, but the Doctor could be
> repeated.
>
> I could ofcourse do a second processing of the resulting object array, but
> still - it would be a more strong
> and flexible solution to do something like this:
>
> select distinct new LightPatient(p.id, p.name, p.lastname, p.city), new
> Doctor(ID(d.accountid), d.name, d.speciality, d.address)
> from ....
>
> But again - let us just start having Hibernate being able to create
> valuebeans for us "on-the-fly" :)
>
> How about the "creating by constructor" vs. "creating and then set by
> properties" approach ?
> I think "creating and then set by properties" is the best in respect to
> ensure that the value beans are initialized with the right
> values because the propertynames are explicit listed opposed to "creating
by
> constructor" where it is the correct sequence and position of the
properties
> that "decides" how the valuebean is created.
> But then again "creating by constructor" has a lean, mean and compact
(read:
> I like it) syntax, it requires only one constructor call (by properties
> requires addtional N setters) and it is probably also the easiest to
> implement.
>
> > > Or
> > >is option 2 just about keeping the old cirrus.hibernate
> >> prefix for those interfaces ?
>
> >I mean its possible to simultaneously have
>
> >cirrus.hibernate.Query
> >net.sf.hibernate.Query
>
> >with the underlying implementation being
>
> >net.sf.hibernate.impl.QueryImpl
>
> Okey - then I'm all for #1. It is waste of good bandwith to manage those
> seperate interfaces :)
>
> >> 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 :)
>
> >Can you enlarge on what exactly you envisage RowSet support
> >would look like? I must admit I don't really find the whole
> >RowSet notion particularly compelling to begin with and I
> >certainly don't know how it would work out in the context
> >of OR mapping where the underlying data model is *much* more
> >complex than a table of simple values. Perhaps you could
> >give an example of code that uses a RowSet in an O/R mapping
> >context and some hints as to the semantics of something like
> >CachedRowSet.....
>
> My primary reason is just being able to provide a uniform "view" onto the
> scalar queries, for which an RowSet is
> a well known interface for accessing tabular data (and scalar queries - or
> any query in Hibernate also "just" result in a tabular result, e.g. a List
> of Object[]).
>
> Thus the first attempt on RowSet would not be to support all the
> write-back/through possibilities of an RowSet (which I think you are
> referring to by mentioning CachedRowSet), but simply to be able to provide
> an interface onto the tabular data that provides something like this:
>
> RowSet rs = session.createRowSet(); // returns an
sf.net.hibernate.RowSet,
> which hold a reference to the session
> rs.setCommand("select distinct new LightPatient(p.id, p.name, p.lastname,
> p.age), doc from Patient as p, Doctor as doc where ...");
>
> ResultSetMetaData rsmd = rs.getMetaData(); // nice to have .... to provide
> uniform access to the result e.g. in a JTable
>
> rs.execute();
> while(rs.next()) {
> String myId = rs.getString("p.id"); // converts the long to an String
> int age = rs.getInt("p.age");
> String name = (Doctor)rs.getObject("doc");
> ...
> }
>
> Personally I find it a strength if Hibernate could provide such an
> interface - and I don't see why it "conflicts" with OR mapping. Remember
> that even since JDBC 1.0 and even more in JDBC 2/3.0 there has been
support
> for having ResultSet's return objects.
>
> /max
>
>
>
>
>
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
