hibernate-devel — development

[Hibernate-devel] 1:n reference to same class

[Christoph S. <ch...@sc...>]

Hi!

Does Hibernate support a 1:n relation to the same type like this:

class X
{
    X parent;
    X getParent()
    {
        return parent;
    }
    ......
}
or will i end up in an infinite loop if this == parent?

regards
 chris

[Hibernate-devel] version 0.9.7

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

please check it out....

main focus is fixes to some nasty nondeterministic bugs.

thanks to those who helped out with this (Doug and Benjamin Chi).

Gavin

distinct (was Re: [Hibernate-devel] 0.9.6)

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

When constructing the SQL for the find

Query#renderSQL() is making an array of persisters. In my case, the
array has a persister for "baz1" followed by a persister for "bar"

The order depends on the iterator returned by types.keySet() in
returnTypes.addAll( types.keySet() );

Since types is a HashMap, the order is implementation dependent.

This leads to
selectIDString= "baz1.idcode as idcode0, bar.foo_id as foo_id1"

later in Query#renderSQL() we have...

    //SELECT
    buf = new StringBuffer("SELECT ");
    distinct=true;
    for ( int i=0; i<size; i++ ) {
        if ( !persisters[i].selectDistinct() ) distinct=false;
        break;
    }

Note that this breaks after the first tested persister no matter what
the outcome. Since baz is first in my case, the select remains
DISTINCT; but it should be ALL. Perhaps this code should be:

    //SELECT
    buf = new StringBuffer("SELECT ");
    distinct=true;
    for ( int i=0; i<size; i++ ) {
        if ( !persisters[i].selectDistinct() ) {
            distinct=false;
            break;
        }
    }

I have made this change in the CVS; it fixes the problem for me. Now
all FooBarTests pass with Mckoi and jdk 1.4.

e

Re[2]: [Hibernate-devel] 0.9.6

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

I just sync'd with cvs ran FooBarTest and got the same problem...

Flushing 0 insertions, 1 updates, 0 deletions to 2 objects and updating 6 collections....
from foo in class cirrus.hibernate.test.Foo where foo.string='from BoogieDown  -tinsel town  =!@#$^&*())'
SELECT foo.foo_id, foo.class, foo.foo, foo.long_, foo.integer_, foo.float_, foo.double_, foo.bytes, foo.date_, foo.timestamp_, foo.boolean_, foo.bool_, foo.null_, foo.short_, foo.zero_, foo.int_, foo.string_, foo.byte_, foo.yesno, foo.blobb_, foo.nullBlob, foo.status_, foo.bin_, foo.first_name, foo.surname, foo.count_, foo.name_, foo.subcount, foo.subname, foo.the_time, foo.baz, foo.bar_string, foo.bar_count, foo.name, foo.importantDates FROM foos foo WHERE 1=1 AND ( ( foo.string_='from BoogieDown  -tinsel town  =!@#$^&*())' ) )
Flushing 2 insertions, 1 updates, 0 deletions to 4 objects and updating 30 collections....
 from bar in class cirrus.hibernate.test.Bar where bar.baz.count=667
SELECT DISTINCT baz1.idcode as idcode0, bar.foo_id as foo_id1, baz1.count_count as count_count0, baz1.name_b as name_b0, baz1.stringSet as stringSet0, baz1.stringDateMap as stringDateMap0, baz1.fooArray as fooArray0, baz1.stringArray as stringArray0, baz1.setArray as setArray0, baz1.stringArrayMap as stringArrayMap0, baz1.setList as setList0, baz1.customs as customs0, bar.class as class1, bar.baz as baz1, bar.bar_string as bar_string1, bar.bar_count as bar_count1, bar.name as name1, bar.importantDates as importantDates1, bar.the_time as the_time1, bar.foo as foo1, bar.long_ as long_1, bar.integer_ as integer_1, bar.float_ as float_1, bar.double_ as double_1, bar.bytes as bytes1, bar.date_ as date_1, bar.timestamp_ as timestamp_1, bar.boolean_ as boolean_1, bar.bool_ as bool_1, bar.null_ as null_1, bar.short_ as short_1, bar.zero_ as zero_1, bar.int_ as int_1, bar.string_ as string_1, bar.byte_ as byte_1, bar.yesno as yesno1, bar.blobb_ as blobb_1, bar.nullBlob as nullBlob1, bar.status_ as status_1, bar.bin_ as bin_1, bar.first_name as first_name1, bar.surname as surname1, bar.count_ as count_1, bar.name_ as name_1, bar.subcount as subcount1, bar.subname as subname1 FROM Baz baz1, foos bar WHERE 1=1 and bar.class in ('cirrus.hibernate.test.Bar')  AND ( ( baz1.count_count=667  and bar.baz = baz1.idcode ) )
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at cirrus.hibernate.test.TestCase.run(TestCase.java:46)
        at cirrus.hibernate.test.FooBarTest.main(FooBarTest.java:1006)
Caused by: com.mckoi.database.jdbc.MSQLException: Can not order by field type VARBINARY in 'bin_'
        at com.mckoi.database.jdbcserver.LocalDatabaseInterface.exec(LocalDatabaseInterface.java:194)
        at com.mckoi.database.jdbcserver.LocalDatabaseInterface.execQuery(LocalDatabaseInterface.java:229)
        at com.mckoi.database.jdbc.MConnection.executeQuery(MConnection.java:265)
        at com.mckoi.database.jdbc.MStatement.executeQuery(MStatement.java:110)
        at com.mckoi.database.jdbc.MPreparedStatement.executeQuery(com/mckoi/database/jdbc/MPreparedStatement.java:72)
        at cirrus.hibernate.impl.RelationalDatabaseSession.find(RelationalDatabaseSession.java:728)
        at cirrus.hibernate.impl.RelationalDatabaseSession.find(RelationalDatabaseSession.java:677)
        at cirrus.hibernate.impl.RelationalDatabaseSession.find(RelationalDatabaseSession.java:601)
        at cirrus.hibernate.test.FooBarTest.testQuery(FooBarTest.java:345)
        ... 6 more

It's also odd that the order of the columns in the select is
different. Is this perhaps another jdk 1.4 versus ibm jvm 1.3 problem?

e

Monday, February 25, 2002, 2:52:24 AM, you wrote:
> Doug, I can't reproduce that result - what i get is:

> SELECT bar.foo_id as foo_id0, baz1.idcode as idcode1, bar.class as class0,
> bar.baz as baz0, bar.bar_string as bar_string0, bar.bar_count as
> bar_count0, bar.name as name0, bar.importantDates as importantDates0,
> bar.the_time as the_time0, bar.foo as foo0, bar.long_ as long_0,
> bar.integer_ as integer_0, bar.float_ as float_0, bar.double_ as double_0,
> bar.bytes as bytes0, bar.date_ as date_0, bar.timestamp_ as timestamp_0,
> bar.boolean_ as boolean_0, bar.bool_ as bool_0, bar.null_ as null_0,
> bar.short_ as short_0, bar.zero_ as zero_0, bar.int_ as int_0, bar.string_
> as string_0, bar.byte_ as byte_0, bar.yesno as yesno0, bar.blobb_ as
> blobb_0, bar.nullBlob as nullBlob0, bar.status_ as status_0, bar.bin_ as
> bin_0, bar.first_name as first_name0, bar.surname as surname0, bar.count_
> as count_0, bar.name_ as name_0, bar.subcount as subcount0, bar.subname as
> subname0, baz1.count_ as count_1, baz1.name_ as name_1, baz1.stringSet as
> stringSet1, baz1.stringDateMap as stringDateMap1, baz1.fooArray as
> fooArray1, baz1.stringArr
> ay as stringArray1, baz1.setArray as setArray1, baz1.stringArrayMap as
> stringArrayMap1, baz1.setList as setList1, baz1.customs as customs1
> FROM foos bar, Baz baz1
> WHERE 1=1 and bar.class in ('cirrus.hibernate.test.Bar')
> AND ( ( baz1.count_=667  and bar.baz = baz1.idcode ) )


> which still has one slight problem: we unnecessarily grab columns from Baz
> that we arent going to use. I will fix that.

> not sure why you are getting a distinct select....

Re: [Hibernate-devel] big improvement

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

> The doco says somewhere that hibernate will do create's before delete's.
> If I use a primary key that's not a synthesised "oid" but a real-world
> attribute (e.g. part-number), as in the case of a legacy DB table
> structure, I get problems when I try to delete one object and then
> re-insert another object with that same primary key value.

> Is this still the case? I know I can split it over two transactions, but
> that's not always possible or desirable.

Yeah this is unchanged and likely to remain so. To fix this would require
really extreme redesign. It would usually be possible to do what you want
to do as an update to the old object, anyway.

Re: [Hibernate-devel] big improvement

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

Gavin_King/Cirrus%CI...@ci... wrote:
> I've just done some work today that removes one of the more annoying
> restrictions. You no longer have to be careful about the order you create
> (), save() and delete() objects in. Hibernate now does all that
> automagically. This also makes use of save() much more desirable and makes
> hibernate more efficient (performance-wise) by side effect :)

I have one question that you might know the answer to off the top of 
your head.

The doco says somewhere that hibernate will do create's before delete's. 
If I use a primary key that's not a synthesised "oid" but a real-world 
attribute (e.g. part-number), as in the case of a legacy DB table 
structure, I get problems when I try to delete one object and then 
re-insert another object with that same primary key value.

Is this still the case? I know I can split it over two transactions, but 
that's not always possible or desirable.

Thanks, PaulS.

[Hibernate-devel] big improvement

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

I've just done some work today that removes one of the more annoying
restrictions. You no longer have to be careful about the order you create
(), save() and delete() objects in. Hibernate now does all that
automagically. This also makes use of save() much more desirable and makes
hibernate more efficient (performance-wise) by side effect :)

for example, previously you couldn't write code like this:

session = fac.openSession();

foo = new Foo();
bar = new Bar();

foo.setBar(bar);
bar.setFoo(foo);

session.save(foo);
session.save(bar);

session.commit();

session = fac.openSession();

// get the same foo and bar

session.delete(foo);
session.delete(bar);
session.commit();

Re: [Hibernate-devel] Progress Dialect

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

Excellent! thanks :)

[Hibernate-devel] Progress Dialect

[Phillip B. <phi...@cl...>]

Attached is a dialect to support the Progress RDBMS v9.1C.  This has 
been tested against Friday's (22nd) CVS and passed all tests.

The connection URL requires a workaround key to resolve an issue in the 
JDBC driver.  The details are in the Javadoc comments.

Phillip B.

Re: [Hibernate-devel] 0.9.6

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

Doug, I can't reproduce that result - what i get is:

SELECT bar.foo_id as foo_id0, baz1.idcode as idcode1, bar.class as class0,
bar.baz as baz0, bar.bar_string as bar_string0, bar.bar_count as
bar_count0, bar.name as name0, bar.importantDates as importantDates0,
bar.the_time as the_time0, bar.foo as foo0, bar.long_ as long_0,
bar.integer_ as integer_0, bar.float_ as float_0, bar.double_ as double_0,
bar.bytes as bytes0, bar.date_ as date_0, bar.timestamp_ as timestamp_0,
bar.boolean_ as boolean_0, bar.bool_ as bool_0, bar.null_ as null_0,
bar.short_ as short_0, bar.zero_ as zero_0, bar.int_ as int_0, bar.string_
as string_0, bar.byte_ as byte_0, bar.yesno as yesno0, bar.blobb_ as
blobb_0, bar.nullBlob as nullBlob0, bar.status_ as status_0, bar.bin_ as
bin_0, bar.first_name as first_name0, bar.surname as surname0, bar.count_
as count_0, bar.name_ as name_0, bar.subcount as subcount0, bar.subname as
subname0, baz1.count_ as count_1, baz1.name_ as name_1, baz1.stringSet as
stringSet1, baz1.stringDateMap as stringDateMap1, baz1.fooArray as
fooArray1, baz1.stringArr
ay as stringArray1, baz1.setArray as setArray1, baz1.stringArrayMap as
stringArrayMap1, baz1.setList as setList1, baz1.customs as customs1
FROM foos bar, Baz baz1
WHERE 1=1 and bar.class in ('cirrus.hibernate.test.Bar')
AND ( ( baz1.count_=667  and bar.baz = baz1.idcode ) )


which still has one slight problem: we unnecessarily grab columns from Baz
that we arent going to use. I will fix that.

not sure why you are getting a distinct select....

[Hibernate-devel] Bugs

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

I have pulled 0.9.6 from the website temporarily, due to the reported
problems. And I was sooo proud of the testsuite.....

:(

Re: [Hibernate-devel] 0.9.6

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

> I released a new version.

Thank you, Gavin. It looks good.

I ran the tests with Mckoi and encountered a few problems.

The first couple were clearly Mckoi specific issues:
- "count" cannot be used as a column name
- quoted '\n' gives the parser fits in a query string

One problem, though, led me to wonder about Hibernate's behavior; in
testQuery the test:

 from bar in class cirrus.hibernate.test.Bar where bar.baz.count=666
 
leads to the SQL:

SELECT DISTINCT baz1.idcode as idcode0, bar.foo_id as foo_id1,
  baz1.counte as counte0, baz1.name as name0, baz1.stringSet as stringSet0,
  baz1.stringDateMap as stringDateMap0, baz1.fooArray as fooArray0, 
  baz1.stringArray as stringArray0, baz1.setArray as setArray0, 
  baz1.stringArrayMap as stringArrayMap0, baz1.setList as setList0, 
  baz1.customs as customs0, bar.class as class1, bar.baz as baz1, 
  bar.bar_string as bar_string1, bar.bar_count as bar_count1, 
  bar.name as name1, bar.importantDates as importantDates1, 
  bar.the_time as the_time1, bar.foo as foo1, bar.long_ as long_1, 
  bar.integer_ as integer_1, bar.float_ as float_1, bar.double_ as double_1, 
  bar.bytes as bytes1, bar.date_ as date_1, bar.timestamp_ as timestamp_1, 
  bar.boolean_ as boolean_1, bar.bool_ as bool_1, bar.null_ as null_1, 
  bar.short_ as short_1, bar.zero_ as zero_1, bar.int_ as int_1, 
  bar.string_ as string_1, bar.byte_ as byte_1, bar.yesno as yesno1, 
  bar.blobb_ as blobb_1, bar.nullBlob as nullBlob1, bar.status_ as status_1, 
  bar.bin_ as bin_1, bar.first_name as first_name1, bar.surname as surname1, 
  bar.count_ as count_1, bar.name_ as name_1, bar.subcount as subcount1, 
  bar.subname as subname1 
  FROM Baz baz1, foos bar 
  WHERE 1=1 and bar.class in ('cirrus.hibernate.test.Bar')  
  AND ( ( baz1.counte=666  and bar.baz = baz1.idcode ) )

=> com.mckoi.database.jdbc.MSQLException:
   Can not order by field type VARBINARY in 'bin_'

I wonder why DISTINCT is used here even though the class Foo (Bar's
superclass) is configured as select="all"; I even tried setting Bar's
select mode explicitly to ALL, and still got DISTINCT. It was only
after setting Baz's mode to ALL that I got it to work.

Anyway, I reported all three problems to to...@mc....

e

[Hibernate-devel] 0.9.6

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

I released a new version. thanks to everyone who contributed to this. the
biggest improvement in this version is not the new features but the
bugfixes and extended test suite which, i believe, really nails down the
existing functionality. I even ran the tests through sistraka's test
coverage analyser and i'm really happy with the results.

Gavin

Re: [Hibernate-devel] Collection Wrappers (was:volunteers?)

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

> The current implementation using addAll() is only a shallow copy, so
> changes to the composition of the set aren't reflected in the copy,
> but changes to mutable elements are visible in both.

> I guess user should expect that!?

Admittedly thats not entirely intuitive. It is at least _determinate_.

We still have 2 other alternatives:

(1) Fully diff the collections
(2) Just not worry about this problem. People should be able to figure out
that they are messing with the collection "behind our back" and not be too
surprised to see some screwy results.

I'm happy with either approach....

Re: [Hibernate-devel] Collection Wrappers (was:volunteers?)

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

<snip>
> Suppose the application passes a subset to hibernate to persist. Hibernate
> wraps it up and tracks changes to it by catching invocations on the
> wrapper. The application might later on (in the same Session, but after a
> flush) change the original set, which changes the subset. But hibernate
> wouldn't know. Well, unfortunately it sometimes _would_ know. Which makes
> the behaviour very undefined. If we _copy_ the original subset, then at
> least we know that changes to the original set will _never_ be reflected
> in the persistent set.

The current implementation using addAll() is only a shallow copy, so
changes to the composition of the set aren't reflected in the copy,
but changes to mutable elements are visible in both.

I guess user should expect that!?

e

Re: [Hibernate-devel] Collection Wrappers (was:volunteers?)

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

> entrysets support "element removal, which removes the corresponding mapping
> from the map, via the Iterator.remove, Set.remove, removeAll, retainAll and
> clear operations".

These are all caught by SetProxy and IteratorProxy.

>  Also we do need to worry about catching setValue().
<snip>
> An alternative (slower) approach might be to fully diff all collections
> against their persistent state (this only happens with arrays now and is
> somewhat harder to implement for Sets and Maps). The thing is that lazy
> initialization requires this cool wrapper class and I'm keen to make use
> of it to save time diffing as well.

Ah, I thought this was true of sets and maps already, which is why I
wasn't concerned about Map.Entry#setValue(). I misinterprested the
comment:
 * Changes to _structure_ of the collection are recorded by the
 * collection calling back to the session. Changes to mutable 
 * elements (ie. composite elements) are discovered by cloning their
 * state when the collection is initialized.
I was wrongly assuming how this was being done.  Now I see.

I've added a new EntrySetProxy EntryIteratorProxy and MapEntryProxy to
Map and used it in SortedMap as well. The MapEntryProxy instances are
created lazily in the iterator. In retrospect I could have extended
SetProxy to create EntrySetProxy -- there are only a few differences,
the biggest, of course, is to use EntryIteratorProxy.

e

[Hibernate-devel] Collection Wrappers (was:volunteers?)

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

> In map.entrySet() you have a comment about wrapping proxies around the
> Map.Entry instances in the set. I don't see why this is necessary. The
> only affective operation on Map.Entry is setValue(); you can't change
> the key. Therefore I don't see any way to use it to change the
> structure of the map. You must use the iterator itself to remove
> elements. So, I implemented this differently in SortedSubMap; if you
> agree, we should change Map#entrySet().

entrysets support "element removal, which removes the corresponding mapping
from the map, via the Iterator.remove, Set.remove, removeAll, retainAll and
clear operations". Also we do need to worry about catching setValue().

I think. Am I wrong?

The less-than-satisfactory present solution is to assume that if they
accessed the entryset, they are going to change something.


> Neither Map nor SortedMap copy the maps supplied in the contructor the
> way the Set and SortedSet do. Is this necessary?

Very Good Question. I added it to Set + SortedSet as an afterthought today.
I think SortedMap and Map also need it. I havn't fully thought this stuff
through and I guess a certain point of view would be not to worry about it:

Suppose the application passes a subset to hibernate to persist. Hibernate
wraps it up and tracks changes to it by catching invocations on the
wrapper. The application might later on (in the same Session, but after a
flush) change the original set, which changes the subset. But hibernate
wouldn't know. Well, unfortunately it sometimes _would_ know. Which makes
the behaviour very undefined. If we _copy_ the original subset, then at
least we know that changes to the original set will _never_ be reflected
in the persistent set.

Now an alternative approach is to just declare "dont try to persist
subsets,
dont try to alter a Map via an entryset or keyset that you created earlier,
etc." The way I envisage that all this functionality will actually be
_used_
by a real application suggests that we shouldn't worry *too* much about
these
more exotic usages...

I do not have a strong opinion about any of this yet.

An alternative (slower) approach might be to fully diff all collections
against their persistent state (this only happens with arrays now and is
somewhat harder to implement for Sets and Maps). The thing is that lazy
initialization requires this cool wrapper class and I'm keen to make use
of it to save time diffing as well.

Re[2]: [Hibernate-devel] volunteers?

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

> The trouble with this approach is I think it will make the rest of the
> code more prone to bugs if its more difficult to distinguish between a
> persistent collection and a view of the persistent collection. And from
> a modelling point of view, what the hell do the following methods
<snip>

OK, that's why I asked.

I modified SortedMap to match your design.

Two questions:

In map.entrySet() you have a comment about wrapping proxies around the
Map.Entry instances in the set. I don't see why this is necessary. The
only affective operation on Map.Entry is setValue(); you can't change
the key. Therefore I don't see any way to use it to change the
structure of the map. You must use the iterator itself to remove
elements. So, I implemented this differently in SortedSubMap; if you
agree, we should change Map#entrySet().

Neither Map nor SortedMap copy the maps supplied in the contructor the
way the Set and SortedSet do. Is this necessary?

e

Re: [Hibernate-devel] volunteers?

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

The trouble with this approach is I think it will make the rest of the
code more prone to bugs if its more difficult to distinguish between a
persistent collection and a view of the persistent collection. And from
a modelling point of view, what the hell do the following methods

     public abstract Iterator entries();
     public abstract Object readFrom(ResultSet rs, CollectionPersister
role) throws Exception;
     public abstract void writeTo(PreparedStatement st, CollectionPersister
role, Object entry, int i) throws Exception;
     public boolean isDirty(java.util.List before, java.util.List after,
Type elementType) throws HibernateException
     public abstract void replaceElements(java.util.Map replacements)
throws HibernateException;

mean for a subset/map?

> I am liking this compromise more and more. I implemented SortedMap
> this way so you'd have a concrete example to evaluate; see cvs. It
> depends on Map.map being non-private, and PeristentCollection read()
> and write() being non-final.

Re: [Hibernate-devel] volunteers?

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

Yeah, I _had_ been drawing a distinction between PersistentCollections,
which represent actual collections on the database, and things like
entrysets, iterators, subsets which represent a view of a persistent
collection. The two things are conceptually different even though,
as you suggest, we could share some code between them. Right now I'm
tending to favor continuing the distinction and _not_ sharing code.

I committed a refactor of the SortedSet code to CVS, for you to have a
look at. We can always roll back to what you had.....

the previous version is tagged v096.

I also committed some probably-badly-concieved code which would let you
make a subset persistent (with all kinds of caveats!)

Gavin

> Please compare your Map.SetProxy with my SortedSet.SubSet
> implementations (and the corresponding differences in your
> PeriststentCollection.IteratorProxy and my SortedSet.WrapIterator).

> I felt squeamish about having a null session in the SubSet (and I'm
> not sure if I need to handle getInitialValue and setSession in the
> SubSet -- I assume not, since the SubSet is already materialized and
> the session has no handle on it). But the advantage of my approach is
> much more code sharing between SubSet and SortedSet (and Set). This
> will be even more pronounced in the SortedMap implementation -- so
> I'll hold off on implementing that until I get your guidance on the
> direction to take.

> An alternative compromise between the two approaches is to add an
> instance variable to SortedSet, backingSet, which would be null for
> the real set, and for subsets it would reference the SortedSet
> superset. Then write() and read() could check backingSet: if it's null
> they would do the usual thing, if not they would delegate. This would
> be compatable with PeristentCollection.IteratorProxy I think.

Re: [Hibernate-devel] volunteers?

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

Earler I said:

> An alternative compromise between the two approaches is to add an
> instance variable to SortedSet, backingSet, which would be null for
> the real set, and for subsets it would reference the SortedSet
> superset. Then write() and read() could check backingSet: if it's null
> they would do the usual thing, if not they would delegate. This would
> be compatable with PeristentCollection.IteratorProxy I think.

I am liking this compromise more and more. I implemented SortedMap
this way so you'd have a concrete example to evaluate; see cvs. It
depends on Map.map being non-private, and PeristentCollection read()
and write() being non-final.

e

Re: [Hibernate-devel] volunteers?

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

Please compare your Map.SetProxy with my SortedSet.SubSet
implementations (and the corresponding differences in your
PeriststentCollection.IteratorProxy and my SortedSet.WrapIterator).

I felt squeamish about having a null session in the SubSet (and I'm
not sure if I need to handle getInitialValue and setSession in the
SubSet -- I assume not, since the SubSet is already materialized and
the session has no handle on it). But the advantage of my approach is
much more code sharing between SubSet and SortedSet (and Set). This
will be even more pronounced in the SortedMap implementation -- so
I'll hold off on implementing that until I get your guidance on the
direction to take.

An alternative compromise between the two approaches is to add an
instance variable to SortedSet, backingSet, which would be null for
the real set, and for subsets it would reference the SortedSet
superset. Then write() and read() could check backingSet: if it's null
they would do the usual thing, if not they would delegate. This would
be compatable with PeristentCollection.IteratorProxy I think.

e

Re: [Hibernate-devel] volunteers?

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

I just put SortedSet.java in the cvs. Let me know what you think. I
needed to make write() non-final in PersistentCollection, and the set
non-private in Set. It seems we've both implemented proxy iterators.

e

Re: [Hibernate-devel] volunteers?

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

> Does anyone want to add support for java.util.SortedSet and
> java.util.SortedMap? The existing code for Map + Set should be a good guide
> on how to do it (and we should be able to inherit from
> cirrus.hibernate.collections.Map, cirrus.hibernate.collections.Map). The
> implementations could be backed by TreeSet, TreeMap.

I will make the two files in cirrus.hibernate.collections

> We would have to add to the mapping DTD (dammit) .... probably an attribute
> called 'sorted' for the <map> and <set> elements would be best.....

What about the Comparator?

Perhaps sorted="true" for the default, and optionally
sorted="class.of.Comparator" for custom comparator?

e

[Hibernate-devel] volunteers?

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

Does anyone want to add support for java.util.SortedSet and
java.util.SortedMap? The existing code for Map + Set should be a good guide
on how to do it (and we should be able to inherit from
cirrus.hibernate.collections.Map, cirrus.hibernate.collections.Map). The
implementations could be backed by TreeSet, TreeMap.

We would have to add to the mapping DTD (dammit) .... probably an attribute
called 'sorted' for the <map> and <set> elements would be best.....

Gavin