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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

> sessionFactory.openDatabinder().toXML(foo);
> 
> does a really nice job of printing an object.....

Isn't that more like:

	sessionFactory.openDatabinder().bind(foo).toXML();

...or is my version out of sync?

Great feature, btw!  

> 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

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

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
>

> 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

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
>
>

> 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()

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

> 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

> 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......

> 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

> 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

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

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

> ( 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...

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

yup, thats exactly the idea....

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

An object relational-mapping (ORM) library for Java

hibernate-devel