hibernate-devel — development

[Hibernate] Oh I'm sick of being nice.

[Gavin K. <ga...@ap...>]

Since certain people are accusing us of FUD in the mailing list of their
project, I might as well publish some info. I've been aware of these kind of
results for a while, but have never ever publicised them.

One of the OJB performance tests has been reimplemented for Hibernate (by
Matt Baird of OJB, and tweaked by me) and heres some numbers. Everyone can
draw their own conclusions. I don't personally put much stock in these kind
of toy test cases. Results like this don't really tell you how a system will
scale with multiple threads / servers. So take all with a grain of salt.

(You should take the third test run as most representative.)

OJB (DB2)
=========
inserting 1000 Objects: 3203 msec
updating 1000 Objects: 1906 msec
querying 1000 Objects: 2235 msec
querying 1000 Objects: 46 msec
deleting 1000 Objects: 1391 msec

inserting 1000 Objects: 1531 msec
updating 1000 Objects: 1562 msec
querying 1000 Objects: 2110 msec
querying 1000 Objects: 828 msec
deleting 1000 Objects: 1375 msec

inserting 1000 Objects: 1500 msec
updating 1000 Objects: 1516 msec
querying 1000 Objects: 1890 msec
querying 1000 Objects: 797 msec
deleting 1000 Objects: 1265 msec


Hibernate (DB2)
===============
inserting 1000 Objects: 1719 msec
updating 1000 Objects: 875 msec
querying 1000 Objects: 1640 msec
querying 1000 Objects: 78 msec
deleting 1000 Objects: 641 msec

inserting 1000 Objects: 891 msec
updating 1000 Objects: 656 msec
querying 1000 Objects: 1422 msec
querying 1000 Objects: 187 msec
deleting 1000 Objects: 656 msec

inserting 1000 Objects: 547 msec
updating 1000 Objects: 625 msec
querying 1000 Objects: 1344 msec
querying 1000 Objects: 16 msec
deleting 1000 Objects: 532 msec

OJB (MySQL)
===========
inserting 1000 Objects: 2218 msec
updating 1000 Objects: 1750 msec
querying 1000 Objects: 2219 msec
querying 1000 Objects: 1438 msec
deleting 1000 Objects: 1125 msec

inserting 1000 Objects: 1312 msec
updating 1000 Objects: 1453 msec
querying 1000 Objects: 1687 msec
querying 1000 Objects: 1500 msec
deleting 1000 Objects: 1125 msec

inserting 1000 Objects: 1297 msec
updating 1000 Objects: 1500 msec
querying 1000 Objects: 1953 msec
querying 1000 Objects: 781 msec
deleting 1000 Objects: 1078 msec

Hibernate (MySQL)
=================
inserting 1000 Objects: 1422 msec
updating 1000 Objects: 1407 msec
querying 1000 Objects: 2125 msec
querying 1000 Objects: 93 msec
deleting 1000 Objects: 891 msec

inserting 1000 Objects: 875 msec
updating 1000 Objects: 1109 msec
querying 1000 Objects: 1766 msec
querying 1000 Objects: 16 msec
deleting 1000 Objects: 765 msec

inserting 1000 Objects: 985 msec
updating 1000 Objects: 921 msec
querying 1000 Objects: 1735 msec
querying 1000 Objects: 15 msec
deleting 1000 Objects: 704 msec

OJB (HSQL)
==========
inserting 1000 Objects: 6360 msec
updating 1000 Objects: 1172 msec
querying 1000 Objects: 609 msec
querying 1000 Objects: 31 msec
deleting 1000 Objects: 375 msec

inserting 1000 Objects: 547 msec
updating 1000 Objects: 953 msec
querying 1000 Objects: 438 msec
querying 1000 Objects: 15 msec
deleting 1000 Objects: 360 msec

inserting 1000 Objects: 578 msec
updating 1000 Objects: 875 msec
querying 1000 Objects: 234 msec
querying 1000 Objects: 16 msec
deleting 1000 Objects: 250 msec

Hibernate (HSQL)
================
inserting 1000 Objects: 890 msec
updating 1000 Objects: 1063 msec
querying 1000 Objects: 890 msec
querying 1000 Objects: 78 msec
deleting 1000 Objects: 344 msec

inserting 1000 Objects: 594 msec
updating 1000 Objects: 781 msec
querying 1000 Objects: 656 msec
querying 1000 Objects: 172 msec
deleting 1000 Objects: 282 msec

inserting 1000 Objects: 437 msec
updating 1000 Objects: 797 msec
querying 1000 Objects: 453 msec
querying 1000 Objects: 16 msec
deleting 1000 Objects: 235 msec

Re: [Hibernate] Enum

[Gavin K. <ga...@ap...>]

If you write a JakartaEnumType, I will integrate it into the next version.
Shouldn't be too difficult.

Gavin

----- Original Message -----
From: <phr...@im...>
To: <hib...@li...>
Sent: Sunday, October 06, 2002 5:35 AM
Subject: [Hibernate] Enum


> hi,
>
> would it be feasible to migrate to using the Enum classes from jakarta
> (lang commons)? in the long run, i think it would greatly reduce the need
> to create adapter classes for these...
>
> best regards,
>      viktor
>
> --
>
>   phr...@im...
>
> --
> http://fastmail.fm - Email service worth paying for. Try it for free
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] Re: writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

Thanks Brad :)

> not sure if changing the element name for arrays was the completely the
> right thing to do - arrays are quite different to collections in java
(which
> is why i did it), but they share some commonality in hibernate.  my array
> handling code is also a bit dodgy.

's cool...

Would you please update hibernate-generic.dtd to reflect the changes you
made to the "generic" format.

> one thing i would have liked to do (but didn't know how) is to write out
the
> class and package names of an explicitely bound object that is left as an
> un-initialized proxy.

Not possible, since we don't know the class of an object until we initialize
it.
(polymorphism).

Gavin

Re: [Hibernate] RE: DistributedCacheConcurrencyStrategy

[Gavin K. <ga...@ap...>]

I *finally* had a chance to look over your work on this: pretty cool, I like
it. Not yet convinced that we want to introduce a JavaGroups dependency into
the main codebase, but you could work on me and I might capitulate :)

> I thought how to achieve maximum flexibility and keep a clean code for the
cache, i came up with the following
> design that makes more sense IMHO than using a
DistributedCacheConcurrency:

> (1) Define a lockserver interface
> (2) Implement a local lockserver
> (3) Implement a centralized lockserver
> (4) Optionally implement a distributed lockserver  ( the one i actually
did but i believe centralized one makes more sense)
 > (5) Refactor the ReadWriteCacheConcurrency: [snip]
> (6) Refactor the <jcs-cache> tag so we can: [snip]

Yup, all thats quite acceptable.

> (7) Add a remove method to the Cache interface so we allow implementation
such the proposed "lightweight readwrite" ( see my previous email) to use
it. Clearly state in the javadoc tag that using this method an
implementation can not fully ensure tx isolation in all case.

Sounds reasonable.


> What is the correct behaviour regarding the lockserver, i believe i did
something wrong in the distributable prototype, i mean when we try to
acquire a lock and the server responds saying the object is already locked.
Should we then go to the database ( what i currently do ) or wait and retry.
> I believe the latter is the correct answer.

Nope, we should go straight to the database. Hibernate threads never ever
wait for each other.

Thanks Christian, sorry for not addressing this sooner. Just been *very*
busy.....

Re: [Hibernate] Re: writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

databinder changes are committed:
1. added setInitializeLazy(boolean) to the Databinder interface.
2. XMLDatabinder now includes associated objects in the document.
3. changed the element name for arrays from collection to array.

not sure if changing the element name for arrays was the completely the
right thing to do - arrays are quite different to collections in java (which
is why i did it), but they share some commonality in hibernate.  my array
handling code is also a bit dodgy.

one thing i would have liked to do (but didn't know how) is to write out the
class and package names of an explicitely bound object that is left as an
un-initialized proxy.

brad

[Hibernate] Enum

[<phr...@im...>]

hi,

would it be feasible to migrate to using the Enum classes from jakarta
(lang commons)? in the long run, i think it would greatly reduce the need
to create adapter classes for these...

best regards,
     viktor

-- 
  
  phr...@im...

-- 
http://fastmail.fm - Email service worth paying for. Try it for free

Re: [Hibernate] Re: writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

> You know this means you are the official owner of the databinding code
now,
> right? ;)

and i am not even using it for what it is meant for :-))

> How about adding
>
> Databinder.setTraverseLazy(boolean)
>
> Thats more flexible and avoids complexifying SessionFactory interface.

no problem, what should the default behaviour be?  i tend to think that it
should be false, but then i don't fully understand the intentional usage of
this class.

i have completed my changes to add associated objects to the document, i
just need to tidy up (sorry where i haven't followed your code conventions).
also, i have changed the element name for arrays from collection to array.

brad

Re: [Hibernate] Re: writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

> You know this means you are the official owner of the databinding code
now,
> right? ;)

and i am not even using it for what it is meant for :-))

> How about adding
>
> Databinder.setTraverseLazy(boolean)
>
> Thats more flexible and avoids complexifying SessionFactory interface.

no problem, what should the default behaviour be?  i tend to think that it
should be false, but then i don't fully understand the intentional usage of
this class.

i have completed my changes to add associated objects to the document, i
just need to tidy up (sorry where i haven't followed your code conventions).
also, i have changed the element name for arrays from collection to array.

brad

[Hibernate] Re: writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> ( object instanceof HibernateProxy ) && ( (HibernateProxy)
> object ).isUninitialized()

Of course, you noticed my mistake, its really:
( object instanceof HibernateProxy ) && ( (HibernateProxy)
 object ).isUninitialized_()

(trailing underscore) so that the methods of the Proxy are less likely to
conflict with the names of methods of the persistent class...

Re: [Hibernate] Network Demo

[Gavin K. <ga...@ap...>]

Thanks Jeff! This is very helpful :)

A couple of points

1. The UML diagram is not quite right. There are only two associations
between edge and vertex. They are both bidirectional associations so they
appear twice in the mapping files.
2. All the website documentation is done in AFT
(http://www.maplefish.com/todd/aft.html) which is very easy to use (much
easier than html). You will need to grab the source files from CVS to see
what they look like. The build script excludes them.

peace

Gavin


----- Original Message -----
From: "Boring, Jeff W, ALBAS" <jb...@at...>
To: <hib...@li...>
Sent: Saturday, October 05, 2002 2:39 AM
Subject: RE: [Hibernate] Network Demo


Gavin, et. al.

Actually, I kind of like the demo now that I understand the model and the
domain. I've tweeted the hibernate-XXX\doc\demo.html a little to help others
with the same problem. These changes include a UML diagram for vertex,
source & edge as well as some explanations about the sample commands.

Just add all the files from the zip to the hibernate-XXX\doc directory.
Enjoy,

Jeff Boring
Custom & Web Services Development
AT&T Labs
jb...@at...

[Hibernate] Re: writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> i have just committed my initial changes to the XMLDatabinder class.  now
 un-initialised proxies and lazy collections can be left un-initialised.
Cool. Thanks Brad :)
You know this means you are the official owner of the databinding code now,
right? ;)

 > i am leaning towards changing openDatabinder() on SessionFactory to
openDatabinder(boolean
 traverseLazy).

How about adding

Databinder.setTraverseLazy(boolean)

Thats more flexible and avoids complexifying SessionFactory interface.

P.S.  Something I've never understood properly is why on earth the Session
interface has two methods suspendFlushes() / resumeFlushes() instead of the
much saner setAutoFlush(boolean) ......

Who designed this shit??!!!?

I'll have to do some deprecation there at some stage. Not sure *what* I was
smoking that day......

RE: [Hibernate] Network Demo

[Boring, J. W, A. <jb...@at...>]

Gavin, et. al.

Actually, I kind of like the demo now that I understand the model and =
the domain. I've tweeted the hibernate-XXX\doc\demo.html a little to =
help others with the same problem. These changes include a UML diagram =
for vertex, source & edge as well as some explanations about the sample =
commands.

Just add all the files from the zip to the hibernate-XXX\doc directory. =
Enjoy,

Jeff Boring
Custom & Web Services Development
AT&T Labs
jb...@at...

Re: [Hibernate] writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

i have just committed my initial changes to the XMLDatabinder class.  now
un-initialised proxies and lazy collections can be left un-initialised.

this behaviour is controlled by the new private boolean field traverseLazy.
for now it is set to true, to reflect the behaviour of this class to date.
i have not provided a mechanism to configure this yet.  i am leaning towards
changing openDatabinder() on SessionFactory to openDatabinder(boolean
traverseLazy).

i have also added the proxy attribute to the property element for an entity
that has a proxy (and the lazy attribute for collections with similar
behaviour).  it can have the values:
  un-initialized
  initialized
  now-initialized - this is set if the proxy was un-initialized and we
initialized the proxy

brad

RE: [Hibernate] Please check out the new locking API

[Boring, J. W, A. <jb...@at...>]

>>=20
Do you think thats better? I don't really...
Anyway, we shouldn't take ODMG as a good model. The ODMG API is an API =
for OO databases, not for OR mappers and so its somewhat badly adapted =
to the task at hand. You can't do this:

database.lookup("name", Transaction.UPGRADE)

using the ODMG API. But for an OR tool that is the most efficient / =
natural way to do things. So in fact, the proposed locking API is just =
as granular as ODMG, but also more efficient in terms of database =
access.=20
<<

Not now, you brought to my attention a very good point that I had not =
considered. Note that I am not experienced with OJB, just trying to =
learn the issues and the approaches.

>> A shared lock is acquired with an SQL "select...". <<

Actually the type of lock, lock duration, granularity and escalation =
depends on the database and the isolation level. But I get your point.

>> There is really no cache-level locking. No thread *ever* blocks or =
recieves an exception when trying to access the cache. The most that =
happens is that one session gains exclusive access to the _cached_ =
representation of the object when it tries to update it. Then all other =
sessions have to go to the database. If you search back through this =
list, you'll see plenty of
previous discussions about how we maintain transaction isolation with =
this approach. <<

I spent several hours reading the treads today, searched on "transaction =
isolation" and "lock isolation" (require all words) and the most helpful =
tread was "RE: Pessimistic locking?" =
(https://sourceforge.net/mailarchive/message.php?msg_id=3D1301809). I =
now understand locking Session.lock() and loadWithLock() - used to =
support pessimistic locking ala select for update.  Thanks for your =
help.=20


Jeff Boring
Custom & Web Services Development
AT&T Labs
jb...@at...

[Hibernate] XML serialization

[Anton v. S. <an...@ap...>]

> Is it
> a good feature but because I never documented it , nobody knows it works

I had seen indications that it existed, and you've referenced it in passing before, iirc, so I didn't realize it was as unofficial as all that.

> a good feature but because I never finished it (missing XML->objects), nobody can use it yet

Ah, but that assumes you need XML->objects.  I have another application in mind, and it may be useful for that.

> a useful feature but the wrong approach

Don't know enough about it yet.

> not really useful to anyone

I would think it has a lot of potential application-level uses.  Most databases these days have a way to get the output of a query as XML.  However, that requires writing the query in SQL.  Your feature has the makings of an equivalent for Hibernate.  One obvious way to use this is for reports, where XSLT or similar XML formatting tools could be used to transform the XML into HTML, PDF or whatever.  This has the potential to eliminate some application-specific code which might otherwise be needed, or at least replace some of that code with stylesheets, which may be simpler (although with XSL, one can't always be sure of that :)

I'm not just looking for ways to use a new feature just because it's there: in applications I'm working on, there's a fair amount of code devoted to generating XML.  I also have a primitive "view framework" which can render HTML views of arbitrary beans based on a metadata repository and a (typically small) view-specific specification.  Generation of XML as well as HTML was something I was planning to add to this framework.  I see some potential synergy here...

Anton

[Hibernate] new locking API - Question:

[Gavin K. <ga...@ap...>]

A question: does the locking API need to distinguish between write locks and
upgrade locks? At the moment I'm considering them both to be "exclusive"
locks, though I know thats not quite the semantics of FOR UPDATE. Actually,
have I got it all wrong and I should use

NONE
READ
UPGRADE
UPGRADE_NOWAIT
WRITE

as the lock modes?

Re: [Hibernate] Please check out the new locking API

[Gavin K. <ga...@ap...>]

> Wouldn't you want to specify locks by the more granular transaction
instead of session? This is how OJB.ODMG does it.

Locks are released at the end of the transaction, obviously. So this is
merely an API issue of how they are exposed to the user. Clearly the lock()
method seems to belong on the Transaction interface. However we also have
the load() method that seems to make most sense on the Session interface. I
suppose we could move both methods to the Transaction interface but then it
would look like:

public interface Transaction {
  public void lock(Object obj, LockMode lock);
  public Object load(Class clazz, Serializable id, LockMode lock);
  public void commit();
  public void rollback();
  public boolean isRolledBack();
  public boolean isCommitted();
}

Do you think thats better? I don't really...

Anyway, we shouldn't take ODMG as a good model. The ODMG API is an API for
OO databases, not for OR mappers and so its somewhat badly adapted to the
task at hand. You can't do this:

database.lookup("name", Transaction.UPGRADE)

using the ODMG API. But for an OR tool that is the most efficient / natural
way to do things. So in fact, the proposed locking API is just as granular
as ODMG, but also more efficient in terms of database access.

> I want to make sure I understand clearly Hibernates "locking."

Hibernate locking is *always* delegated to the database. I STRONGLY believe
that this is the best design. I have some understanding of OJB's alternate
approaches and I also have some idea of their performance/scalability
impact. OJB uses methods like a seperate lock table on the database, or runs
in client / server mode where middle tier servers connect to the OJB server
rather than direct to the database. (Please correct me if I'm wrong.) This
is *not* the approach here.

* Hibernate is a library
* Hibernate is designed to work happily alongside legacy applications and
other instances of Hibernate which have simultaneous access to the same
database

This means _no_wierd_locking_schemes_. Databases already implement locking
much better than we could. An exclusive lock is acquired with an SQL
"select..for update". A shared lock is acquired with an SQL "select...".

> There are 2 distinct issues, object cache locking verses RDBMS locking.
Locking as discussed here has to do with the object cache, not
share/exclusive locks applied to the rows of the database (for RDBMS with
row level locking)? Right? RDBMS locking is controlled solely by the
isolation level and the specific DML issued, right?

There is really no cache-level locking. No thread *ever* blocks or recieves
an exception when trying to access the cache. The most that happens is that
one session gains exclusive access to the _cached_ representation of the
object when it tries to update it. Then all other sessions have to go to the
database. If you search back through this list, you'll see plenty of
previous discussions about how we maintain transaction isolation with this
approach.

RE: [Hibernate] Please check out the new locking API

[Boring, J. W, A. <jb...@at...>]

Gavin:

Wouldn't you want to specify locks by the more granular transaction =
instead of session? This is how OJB.ODMG does it.

I want to make sure I understand clearly Hibernates "locking." There are =
2 distinct issues, object cache locking verses RDBMS locking. Locking as =
discussed here has to do with the object cache, not share/exclusive =
locks applied to the rows of the database (for RDBMS with row level =
locking)? Right? RDBMS locking is controlled solely by the isolation =
level and the specific DML issued, right?

-----Original Message-----
From: Gavin King [mailto:ga...@ap...]
Sent: Wednesday, October 02, 2002 2:42 AM
To: hibernate list
Subject: [Hibernate] Please check out the new locking API


Could people do me a favor + check out the new locking API and let me =
know
what they think. 'Cos if no-one else has any very strong opinions on =
this
stuff, I might as well release it in the next version.

TIA

Gavin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
hibernate-devel mailing list
hib...@li...
https://lists.sourceforge.net/lists/listinfo/hibernate-devel

Re: [Hibernate] writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> actually i meant (2) - but u r right about circular references.  so i will
> fall back to (1), and since the uid is currently printed, u would be able
to
> visually link things up.

Also the stylesheet generates XML ids for each entity.

>
> i was just looking at the XMLDatabinder source and cannot see a way to
tell
> if a proxy or collection is initialised.

( object instanceof HibernateProxy ) && ( (HibernateProxy)
object ).isUninitialized()

Re: [Hibernate] writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

actually i meant (2) - but u r right about circular references.  so i will
fall back to (1), and since the uid is currently printed, u would be able to
visually link things up.

i was just looking at the XMLDatabinder source and cannot see a way to tell
if a proxy or collection is initialised.

brad

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Brad Clow" <bra...@wo...>
Cc: "hibernate list" <hib...@li...>
Sent: Wednesday, October 02, 2002 8:34 PM
Subject: Re: [Hibernate] writing the properties of a persistent object to a
string


>
> > 2. entities recursively printed.
>
> Do you mean that
>
> 1. associated objects get automatically bound to the same document, or
> 2. their representation is nested inside the parent object?
>
> If (1), thats probably a wothwhile idea.....it might even be worth
> overloading the semantics of cascade="all" to automatically bind only
> lifecycle objects. (This would save problems of binding the whole
universe.)
>
> If (2), that can be accomplished with a stylesheet, but its actually not
> desirable since you don't know what to do with circular/shared references.
>
> Anyway, I think you mean (1) ... which is cool
>
>

Re: [Hibernate] writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> 2. entities recursively printed.

Do you mean that

1. associated objects get automatically bound to the same document, or
2. their representation is nested inside the parent object?

If (1), thats probably a wothwhile idea.....it might even be worth
overloading the semantics of cascade="all" to automatically bind only
lifecycle objects. (This would save problems of binding the whole universe.)

If (2), that can be accomplished with a stylesheet, but its actually not
desirable since you don't know what to do with circular/shared references.

Anyway, I think you mean (1) ... which is cool

Re: [Hibernate] writing the properties of a persistent object to a string

[Brad C. <bra...@wo...>]

i just tried it out and it does most of what i was trying to achieve.

like i said in my original post, i am looking for a dynamic way to write out
the state of a persistent object as a string for logging/debugging, so i am
not concerned with the xml binding side of things.

to fulfill my requirements i would like to see (and am happy to work on the
implementation):

1. a way to configure whether proxy's or lazily initialised collections are
initialised and printed or whether they r left uninitialised and just
printed that they r a proxy or that the collection is lazy.  i was thinking
that this behaviour could simply be controlled by a settable boolean
property on the Databinder interface.  however, since a Databinder isn't
currently re-usable, perhaps a openDatabinder(boolean) method on the
SessionFactory is easier.

2. entities recursively printed.

brad

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Anton van Straaten" <an...@ap...>; "hibernate list"
<hib...@li...>
Sent: Wednesday, October 02, 2002 6:03 PM
Subject: Re: [Hibernate] writing the properties of a persistent object to a
string


>
> > Isn't that more like:
> >
> > sessionFactory.openDatabinder().bind(foo).toXML();
>
> yes, of course. my bad
>
> > Great feature, btw!
> >
>
>
>
> Is it?? I've never noticed anyone actually using this stuff, so I just let
> it sit and go moldy. I was never sure *why*; Is it
>
> * a good feature but because I never documented it , nobody knows it works
> * a good feature but because I never finished it (missing XML->objects),
> nobody can use it yet
> * a useful feature but the wrong approach
> * not really useful to anyone
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate] writing the properties of a persistent object to a string

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

Gavin King wrote:

>Is it?? I've never noticed anyone actually using this stuff, so I just let
>it sit and go moldy. I was never sure *why*; Is it
>
>* a good feature but because I never documented it , nobody knows it works
>
Yup.

-Mark

Re: [Hibernate] writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> Isn't that more like:
>
> sessionFactory.openDatabinder().bind(foo).toXML();

yes, of course. my bad

> Great feature, btw!
>



Is it?? I've never noticed anyone actually using this stuff, so I just let
it sit and go moldy. I was never sure *why*; Is it

* a good feature but because I never documented it , nobody knows it works
* a good feature but because I never finished it (missing XML->objects),
nobody can use it yet
* a useful feature but the wrong approach
* not really useful to anyone

Re: [Hibernate] writing the properties of a persistent object to a string

[Gavin K. <ga...@ap...>]

> ...or am I being thick, and most stringifying can pretty much be done with
> toXML and an appropriate stylesheet?
>

yup, thats exactly the idea....