hibernate-devel — development

Re: [Hibernate-devel] mvc & lazy loading

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

Hi Brad!

This subject is an interesting one that I was also thinking of lately.
I did a test app with maverick (mav.sourceforge.net), and there it was
really easy. If the controller(=model) implements ModelLifetime, a discard
function is called when the views are finished and the model is discarded.
There I closed my session. Other frameworks that just forward to the view
dont offer this functionality.
For most of my stuff I use webwork, so I'd like a solution that works there
too. I was thinking of closing the session in the finalize method of my
controller, but then I dont really know when the session will be closed.
Another possibility would be to to pass the session to velocity, and close
it in the velocity view servlet after all is rendered.

How did you implement it?

regards
 chris
----- Original Message -----
From: "Brad Clow" <bra...@wo...>
To: <hib...@li...>
Sent: Tuesday, August 27, 2002 12:38 AM
Subject: [Hibernate-devel] mvc & lazy loading


>
> to date, we have avoided using lazy loading when writing a web app in
> one of the standard mvc type frameworks (eg. struts, webwork, etc).
> this is because objects r typically retrieved, placed in the request
> attributes, session closed and control is then passed to the view (JSP,
> velocity, etc).  if the view attempts to access a lazy loaded collection
> in one of the objects an exception is thrown as the associated session
> is closed.
>
> what do other people do?
>
> yesterday, i spent a few hours writing a very simple webapp framework
> that uses velocity for the view.  it enables the velocity rendering to
> be done while a session is open.  so far this is working quite well for
> us.
>
> comments?
>
> brad
>
> > _______________________________
> > brad clow
> > chief technical officer
> > workingmouse
> >
> > email: bra...@wo...
> > web:   http://www.workingmouse.com
> >
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
>
https://www.inphonic.com/r.asp?r____________________________________________
___
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate-devel] Problem with Session.update()

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

>I'm having a problem with Session.update().  After performing a
>Session.save() on an object, I change one property and call
>Session.update() on it.

Okay, just to be sure, because many new users think that you need to do
this kind of thing:

s = f.openSession();
Foo f = new Foo();
s.save(f);
f.setBar("bar");
s.update(f); // unnecessary step!!
s.flush();
s.connection.commit();
s.close();

I assume you are doing something like the following:

s = f.openSession();
Foo f = new Foo();
s.save(f);
s.flush();
s.connection.commit();
s.close();

f.setBar("bar");

s = f.openSession();
s.update(f); // necessary this time...
s.flush();
s.connection.commit();
s.close();


>How is this possible given that it just saved the object correctly?  Any
>help would be appreciated.

hmmm....youre going to have to give a bit more info than that.....

like perhaps posting a mapping file + the actual code might be enough for
me to spot the problem. (Best of all is to send a JUnit test that
reproduces it, of course.)

[Hibernate-devel] Problem with Session.update()

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

Hi all...

I'm having a problem with Session.update().  After performing a 
Session.save() on an object, I change one property and call 
Session.update() on it.  The save goes through ok, but the update 
results in:

Aug 26, 2002 6:20:23 PM cirrus.hibernate.helpers.JDBCExceptionReporter 
logExceptions
WARNING: SQL Error: 1747, SQLState: 42000
Aug 26, 2002 6:20:23 PM cirrus.hibernate.helpers.JDBCExceptionReporter 
logExceptions
SEVERE: ORA-01747: invalid user.table.column, table.column, or column 
specification

How is this possible given that it just saved the object correctly?  Any 
help would be appreciated.  I'm using Hibernate 1.1b9.  BTW Gavin, the 
new Sesison.save() works like a charm!

Thanks,
-Mark

[Hibernate-devel] mvc & lazy loading

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

to date, we have avoided using lazy loading when writing a web app in
one of the standard mvc type frameworks (eg. struts, webwork, etc).
this is because objects r typically retrieved, placed in the request
attributes, session closed and control is then passed to the view (JSP,
velocity, etc).  if the view attempts to access a lazy loaded collection
in one of the objects an exception is thrown as the associated session
is closed.

what do other people do?

yesterday, i spent a few hours writing a very simple webapp framework
that uses velocity for the view.  it enables the velocity rendering to
be done while a session is open.  so far this is working quite well for
us.

comments?

brad

> _______________________________
> brad clow
> chief technical officer
> workingmouse
>=20
> email: bra...@wo...
> web:   http://www.workingmouse.com
>=20

Re: [Hibernate-devel] proposed API change

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

Gavin_King/Cirrus%CI...@ci... wrote:

>Secondly, some people would like insert() to cascade to insert(). Whereas
>other times insert() to save() is appropriate.
>  
>

Which reminds me:  what happens when I need insert() to cascade to 
insert()?  Is there some workaround?

-Mark

Re: [Hibernate-devel] proposed API change

[Dirk O. <di...@xa...>]

[...]
> So I would like to deprecate the following methods:
>
>   Session.insert(Object)
>   Session.insert(Object, Serializable)
>
> and add the following method
>
>   Session.save(Object, Serializable)
>
> (which does exactly what Session.insert(Object, Serializable) used to
> do.)

I'd say go for it. Although I didn't do too much with Hibernate in the
past, I was always a little bit annoyed about the distinction between
save() and insert(). This should really be handled by the framework not by
the developer.

-dirk

-- 
Anyway kids, have fun, play nicely, be good. And remember - if it ain't
broke, hit it again.

[Hibernate-devel] outline class diagram

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

I did a rough class diagram showing the main Hibernate implementation
classes. Spent ages trying to do it in ArgoUML, but its just too bugy/leaky
to be usable at this stage. Anyways, I'm sceptical about the value of
graphical techniques, but this might help demistify the important
relationships a little:

http://hibernate.sourceforge.net/hibernate-design.jpg

[Hibernate-devel] IDGenerationException

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

Perhaps the proposed API change would remove the need for this, but it 
would be great if the message for IDGenerationException in the event of 
an unassigned id to also report which class is missing the id.

Cheers,
-Mark

Re: [Hibernate-devel] proposed API change

[Jon L. <jon...@xe...>]

I like this change...  All of the developers I have introduced Hibernate to
have had this problem.  They all thought (because of the names of the
methods) that each method would do what the other one did.

My 2 cents...

Jon...

----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: <hib...@li...>
Sent: Sunday, August 25, 2002 7:57 AM
Subject: [Hibernate-devel] proposed API change


> In this post:
>
> http://sourceforge.net/forum/forum.php?thread_id=722838&forum_id=128638
>
> Yaron Zakai makes a suggestion I quite like.
>
> I've seen that new users often have trouble realizing they need to use
> insert() instead of save() when they want to use application-assigned ids.
> People seem to expect that the "assigned" id generator will just use the
> existing id of an object when you call save().
>
> Secondly, some people would like insert() to cascade to insert(). Whereas
> other times insert() to save() is appropriate.
>
> So I would like to deprecate the following methods:
>
>   Session.insert(Object)
>   Session.insert(Object, Serializable)
>
> and add the following method
>
>   Session.save(Object, Serializable)
>
> (which does exactly what Session.insert(Object, Serializable) used to do.)
>
> Then we would deprecate the IDGenerator interface and replace it with:
>
> public interface IdentifierGenerator {
>   public Serializable generate(SessionImplementor session, Object entity)
>     throws ..... ;
> }
>
> Then the assigned id generator would return the current value of the
> entity's id property, instead of throwing an exception.
>
> So instead of:
>
>   session.insert(o)
>
> you use
>
>   session.save(o)
>
> This would allow a save() to cascade to either an "insert" or a "save"
> depending upon the id generator in use. You can still always assign your
> own id (regardless of what id generator is used) by calling
>
>   session.save(o, id)
>
> In favor of this change:
>
>  * it won't break any existing code
>  * its more flexible
>  * its more understandable to new users
>  * its very easy to implement
>
> On the downside, it requires deprecations of methods on the central API
> interface, which is not something that should be done without due
> consideration.
>
> NEways this feels right to me. Opinions?
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

[Hibernate-devel] proposed API change

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

In this post:

http://sourceforge.net/forum/forum.php?thread_id=722838&forum_id=128638

Yaron Zakai makes a suggestion I quite like.

I've seen that new users often have trouble realizing they need to use
insert() instead of save() when they want to use application-assigned ids.
People seem to expect that the "assigned" id generator will just use the
existing id of an object when you call save().

Secondly, some people would like insert() to cascade to insert(). Whereas
other times insert() to save() is appropriate.

So I would like to deprecate the following methods:

  Session.insert(Object)
  Session.insert(Object, Serializable)

and add the following method

  Session.save(Object, Serializable)

(which does exactly what Session.insert(Object, Serializable) used to do.)

Then we would deprecate the IDGenerator interface and replace it with:

public interface IdentifierGenerator {
  public Serializable generate(SessionImplementor session, Object entity)
    throws ..... ;
}

Then the assigned id generator would return the current value of the
entity's id property, instead of throwing an exception.

So instead of:

  session.insert(o)

you use

  session.save(o)

This would allow a save() to cascade to either an "insert" or a "save"
depending upon the id generator in use. You can still always assign your
own id (regardless of what id generator is used) by calling

  session.save(o, id)

In favor of this change:

 * it won't break any existing code
 * its more flexible
 * its more understandable to new users
 * its very easy to implement

On the downside, it requires deprecations of methods on the central API
interface, which is not something that should be done without due
consideration.

NEways this feels right to me. Opinions?

Re: [Hibernate-devel] one-to-one mapping

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

A one-to-one association means the two rows have the same primary key
value.

[Hibernate-devel] one-to-one mapping

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

Hi all...

Can anyone tell me how a one-to-one mapping knows which row to pull to 
instantiate the persistent object?

Thanks,
-Mark

[Hibernate-devel] a favor....

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

Some users have been asking me for example code of Hibernate used

1. from a session bean
2. from a BMP entity bean

I actually don't have time to put together examples at present (theres a
bunch of other issues to address).

Would someone here who has some simple examples of these patterns like to
share them with other users .... or even write some simple examples from
scratch?

Doesn't have to be much ... just enough to get people started. It certainly
doesn't need to be a whole working application. Just the EJB itself and
persistent classes would be enough.

I'd really appreciate the help...

Gavin

P.S. the session bean is most important 'cos thats a recommended
architecture.

Re: [Hibernate-devel] Question:

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

>as for ms sqlserver, a multi-column index is a candidate if the first
column
>of the index is used in the where clause.  is the key column the first
>column in the index?

Cool, thanks Brad. I just asked an Oracle guy here and he told me the same
thing. So it sounds like this is pretty much the usual thing.

I will swap the order of the key + index columns in the PK constraint and
then get rid of the extra index.

[Hibernate-devel] Plans (was: Volunteers?)

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

>Hmm...  Do you have any idea how long this would take?  This is one
>feature I'm in desparate need of...

Well, for really obvious reasons, i'm not committing to any kind of dates
for new features. However....

I want to get a bugfree, well-documented 1.1 out the door as the highest
priority. I still think this is very close but two more issues came up last
night (along with a couple of bad bugs I fixed). As usual with these
things, it will be finished when its finished.

I am then going to take a week or so away from actual development to have a
life for a bit - though I may put in a bit of work on design documentation
in ArgoUML.

My original plan was to then sit down and start building a really good
example application using Hibernate and WebWork but I realise that people
are crying out for this new feature, so I might put that (the example app)
off until later.

Then "normalized mappings" is the first thing I will be looking at. (And
the only new feature I plan for 1.2)

So I suppose in about a month we might be seeing some working versions of
1.2. But thats not a promise, understand.

If I could spend all my time just developing new features then I would, but
there are other equally important things that suck up a lot of time
(documentation, answering questions in the user forum, performance testing,
etc).

Re: [Hibernate-devel] Question:

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

gavin

probably not, but that is going to dependant on each rdbms.

as for ms sqlserver, a multi-column index is a candidate if the first column
of the index is used in the where clause.  is the key column the first
column in the index?

for operations that only select the key, an index only on the key column
would possibly be of more benefit.  the downside is you take a performance
hit on maintaining the extra index on inserts and updates.

brad

----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: <hib...@li...>
Sent: Thursday, August 22, 2002 7:59 PM
Subject: [Hibernate-devel] Question:


>
> I've enhanced SchemaExport to create primary key constraints for indexed
> collections ( consisting of the key + index columns ). I'd like to know if
> its still worth creating an index on the key columns if there is a primary
> key on the key + index columns. Collection retrieval uses the key columns
> only.
>
> A bit beyond my understanding of databasey stuff i'm afraid....
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

Re: [Hibernate-devel] Volunteers?

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

Gavin_King/Cirrus%CI...@ci... wrote:

>>What feature do you mean exactly with "normalized table mappings"?
>>Subcasses that map to diiffenent tables?
>>    
>>
>
>Yup. So you fetch the object using an outerjoin accross the table of the
>superclass and the table of the subclass. This is the only remaining thing
>thats bothering me about the core functionality.
>  
>

Hmm...  Do you have any idea how long this would take?  This is one 
feature I'm in desparate need of...

BTW, how do people handle subclasses at the moment?  I've a base class 
that has very few properties, and many subclasses that add a lot of 
additional information.  I cannot keep all that data in the same table, 
and don't really want to denormalize my tables.

Thanks,
-Mark

[Hibernate-devel] Question:

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

I've enhanced SchemaExport to create primary key constraints for indexed
collections ( consisting of the key + index columns ). I'd like to know if
its still worth creating an index on the key columns if there is a primary
key on the key + index columns. Collection retrieval uses the key columns
only.

A bit beyond my understanding of databasey stuff i'm afraid....

Re: [Hibernate-devel] clustering in a cache

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

>Just out of curiosity: Is it possible to run hibernate with a distributed
>jcs read write cache in a cluster, and did anyone try that yet?

ah - dont go there.... you could maybe experiment with a distributed cache
for "read-only" data but JCS would need to support transactional access to
use it for a distributed "read-write" cache.....

[Hibernate-devel] clustering in a cache

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

Hi All!

Just out of curiosity: Is it possible to run hibernate with a =
distributed jcs read write cache in a cluster, and did anyone try that =
yet?=20

regards
 chris

Re: [Hibernate-devel] Dates + Times

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

>if we had to copy them each time we took a
>snapshot then we would also need to create two new java.util.Calendars
each
>time we compared them (rather than using ==).

I realise this sounds really bad.... Actually the code to compare
dates/times looks something like:

if (x==y) return true;
Calendar c1 = Calendar.getInstance();
Calendar c12 = Calendar.getInstance();
c1.setTime(x);
c2.setTime(y);
........

So what I meant was: if you treat them as immutable + so don't take a copy
when you capture the snapshot state, you get a shortcut exit from that
section of code before you create the Calendars.

Now if only the stupid Calendar class would allow threadsafe usage eg:

calendar.get(Calendar.DAY, date)

then this wouldn't be an issue.....

[Hibernate-devel] Re: Dates + Times

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

Actually - I just took a closer look at the code and realised my last post
was wrong....

The current functionality actually *does* copy dates + times. This occurs
even though DateType, TimeType and TimestampType all extend ImmutableType.

So it looks like I had intended to make the performance optimization I
mentioned - but then didn't actually do it properly. Since existing
applications might depend upon the current functionality I can't really do
it now. *yick*

I will refactor the Type heirarchy to have DateType, TimeType,
TimestampType extend NullableType rather than ImmutableType to currectly
reflect their actual behaviour.

At least this will mean theres no gotcha to document....

[Hibernate-devel] Dates + Times

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

Currently Hibernate treats Dates, Times and Timestamps as immutable types.
In fact, java.util.Date has a single non-deprecated mutator method, setTime
(). My understanding of common Java usage is that this method is rarely, if
ever, used.

There are fairly good performance reasons for continuing to treat
dates/times as immutable; if we had to copy them each time we took a
snapshot then we would also need to create two new java.util.Calendars each
time we compared them (rather than using ==). Creating three objects (four
including the Timezone) per date property per flush is an overhead I would
rather avoid. I mean, its not going to bring the system to a halt but its
still undesirable.

If anyone uses setTime() commonly, or knows of a reason why it is useful,
please let me know so I can change this implementation (or at least make it
configurable). So far I don't know of anyone being tripped up by this which
kinda confirms my impression that setTime() is not really useful...

At the very least I need to document this particular "gotcha".

Gavin

Re: [Hibernate-devel] Volunteers? [alter schema]

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

Hi  viktor!


----- Original Message -----
From: <phr...@im...>
To: "Christoph Sturm" <ch...@mc...>; "Christoph Sturm"
<ch...@sc...>; <Gavin_King/Cirrus%CI...@ci...>
Cc: <hib...@li...>
Sent: Tuesday, August 20, 2002 7:39 PM
Subject: Re: [Hibernate-devel] Volunteers? [alter schema]


> > I was thinking about diffing against jdbc metadata. What I had in mind
was
> > an automatic check of the database metadata when hibernate starts up,
and
> > automatic execution of ddf statements that add missing columns and
tables.
>
> even this poses some problems, eg. when you're trying to add a NOT NULL
> column... also, renaming a column would not be recognized... so i think
> the closest you can get is a schema comparison, and a default alter
> script, which you have to tweak manually. still comes handy though, but
> has not much to do with hibernate itself i guess :)

IMHO this has a lot to do with hibernate, since it makes sure that you can
just deploy a new version of your software, that has additional columns, and
it will just work. Declaring values not null is not really necessary here,
and renaming columns too. If you need to set a column not null, you can
still do that later by hand after assigning a default value.

peace
 chris

Re: [Hibernate-devel] Versioning via Timestamps

[Sven W. <s_...@in...>]

> > I want you to know that "ant clean" wipes out the directory hibernate is
> >installed due to relative-path-addressing problems (ok, thats easy to
> fix).
>
> heheh true. thats fixed now.
I just thought that hibernate might be a "cleanroom" implementation. <g>

> >Feature Request:
> >It would be nice if hibernate could support versioning via timestamps.
>
> Did you have in mind timestamps written by Hibernate (which is trivially
> easy to implement) [...]
Yes, simple plain timestamps that are written by hibernate and are used
for versioning by hibernate. I think this is a common pattern and should
be supported by hibernate to be compatible with other O/R-Mappers (e.g.
mvcsoft) or legacy code.

bye
  Sven