hibernate-devel — development

Re: [Hibernate-devel] database native keys

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

That all looks really good, chris.

(There was one tiny problem where the insert string was wrong for a table
with no other columns but thats a far-from-typical case.)

I have a question:

If, in a single transaction, I delete a row of a table and then insert a
new row, is it likely that the inserted row would get the same generated id
as the deleted row?

Re: [Hibernate-devel] database native keys

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

Ok, I have now checked in the database native keygeneration. It should 
work for MySQL and mssql/sybase.

To use it just use
       <generator class="native"/>

I hope all works ok.

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

>>ok, then its not possible. I will add a check that the native
>>idgenerator is not used for a collection.
>>
>
>yep, cool.
>
>I don't think the lack of native key generation for toplevel
>collections is a big deal. I don't think other O/R mapping
>tools even _have_ such a concept as toplevel collections....
>
>(We really have them mainly because we have subcollections.)
>
>
>_______________________________________________
>Hibernate-devel mailing list
>Hib...@li...
>https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>

Re: [Hibernate-devel] database native keys

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

> ok, then its not possible. I will add a check that the native
> idgenerator is not used for a collection.

yep, cool.

I don't think the lack of native key generation for toplevel
collections is a big deal. I don't think other O/R mapping
tools even _have_ such a concept as toplevel collections....

(We really have them mainly because we have subcollections.)

Re: [Hibernate-devel] database native keys

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

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

>Ah! duh, of course, didn't realise ..... you are using native key
>generation
>for a toplevel collection! Hadn't even occured to me.
>
>CollectionPersister.updateID() does the key generation for collections if
>you want to have a look.
>
>Is it even possible to use native key generation for collections??
>
>They don't have primary keys.... I mean, there are multiple rows, with the
>same key. I've no idea how this would work. (I've never ever used native
>key
>generation myself, so excuse my ignorance.)
>
>
>
ok, then its not possible. I will add a check that the native 
idgenerator is not used for a collection.

Re: [Hibernate-devel] unit tests dont work on all databases

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

I just ran the tests on MS SQL with the JSQL driver
(http://www.j-netdirect.com/) - no problems.

Hibernate certainly does not work with Microsoft's JDBC driver (because its
crap) and this fact is metioned in the documentation. I never tried with
the other driver you mentioned.

[Hibernate-devel] unit tests dont work on all databases

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

Hi All!

I tried to run the unit tests, but it worked only with mysql. When I was
trying with mssqlserver, it did not work, neither with the microsoft
driver nor with the inet sprinta driver. Can someone else try to run the
test with sql server, and give me some feedback if it works?

regards
  chris

[Hibernate-devel] unit tests dont work on all databases

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

Hi All!

I tried to run the unit tests, but it worked only with mysql. When I was 
trying with mssqlserver, it did not work, neither with the microsoft 
driver nor with the inet sprinta driver. Can someone else try to run the 
test with sql server, and give me some feedback if it works?

regards
 chris

Re[2]: [Hibernate-devel] SAP DB dialect

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

>> the default column name for the hilo generator is next.  this is a reserved
>> word in sap db and cannot be used as a column name without being enclosed in
>> double quotes.

> Okay, we better change the default column name. *yick* this will affect
> people - thats kind of painful :(

I have two alternate suggestions:
- make it dialect specific, or
- make it "next" (with quotes)
These should be backward compatible.

e

Re: [Hibernate-devel] SAP DB dialect

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

> i am writing a sap db dialect, (which is proving more painful than
> originally expected :-)).

> the default column name for the hilo generator is next.  this is a
reserved
> word in sap db and cannot be used as a column name without being enclosed
in
> double quotes.

Okay, we better change the default column name. *yick* this will affect
people - thats kind of painful :(

Make it next_hi that can't possibly be reserved anywhere.

Thanks for helping out, Brad.

If you send me your sourceforge username I can give you CVS access
otherwise
just mail me the dialect when you're done.

Re: [Hibernate-devel] SAP DB dialect

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

> i am writing a sap db dialect, (which is proving more painful than
> originally expected :-)).

> the default column name for the hilo generator is next.  this is a
reserved
> word in sap db and cannot be used as a column name without being enclosed
in
> double quotes.

Okay, we better change the default column name. *yick* this will affect
people - thats kind of painful :(

Make it next_hi that can't possibly be reserved anywhere.

Thanks for helping out, Brad.

If you send me your sourceforge username I can give you CVS access
otherwise
just mail me the dialect when you're done.

Re: [Hibernate-devel] database native keys

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

it would make sense for the creation of the test case schema(s) and the
running of the test cases to be ant tasks.  if i get time, i will look at
this sometime in the next week or so.

brad

----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: "Christoph Sturm" <ch...@sc...>
Cc: <hib...@li...>
Sent: Wednesday, March 06, 2002 2:46 AM
Subject: Re: [Hibernate-devel] database native keys


>
> > One problem that i realized now is that the Classpersister is not aware
> > of the DatabaseDialect. The Database Dialect is only set when a schema
> > is generated. For the database native keys to work, it will be necessary
> > that this Property is set. I'm quite happy with it being a property,
> > because i want to use one mapping file for different databases.
>
> A recent change made the SessionFactory know the dialect. If necessary,
> pass it in to RelationalDatabaseSession. The 0.9.8 will be the first
> version where hibernate will issue platform-dependent SQL at runtime.
> Thats okay, it had to happen eventually....
>
> > One more thing: How can I run the unit tests? Is this documented
> somewhere?
>
> Not documented. Guess it should be. Its easy enough, just run FooBarTest
> from the main method, passing in the name of the database as an argument.
> It will need to be able to find connection.properties and you will need
> to edit connection.properties with the correct values for you db.
>
>
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

[Hibernate-devel] SAP DB dialect

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

i am writing a sap db dialect, (which is proving more painful than
originally expected :-)).

the default column name for the hilo generator is next.  this is a reserved
word in sap db and cannot be used as a column name without being enclosed in
double quotes.

two obvious solutions spring to mind:
1. change the default column name - that seems to involve changing line 31
in RelationalDatastore.java and line 42 in HiLogGenerator.java.

2. enclose column names (and probably table names as well) in quotes.  much
bigger change.  i guess this would involve changing both the ddl generation
statements and the dml generation statements.  i am not sure if double
quotes are standard, so the dialect may also need to define the quote to
use.

brad

Re: [Hibernate-devel] database native keys

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

> One problem that i realized now is that the Classpersister is not aware
> of the DatabaseDialect. The Database Dialect is only set when a schema
> is generated. For the database native keys to work, it will be necessary
> that this Property is set. I'm quite happy with it being a property,
> because i want to use one mapping file for different databases.

A recent change made the SessionFactory know the dialect. If necessary,
pass it in to RelationalDatabaseSession. The 0.9.8 will be the first
version where hibernate will issue platform-dependent SQL at runtime.
Thats okay, it had to happen eventually....

> One more thing: How can I run the unit tests? Is this documented
somewhere?

Not documented. Guess it should be. Its easy enough, just run FooBarTest
from the main method, passing in the name of the database as an argument.
It will need to be able to find connection.properties and you will need
to edit connection.properties with the correct values for you db.

Re: [Hibernate-devel] database native keys

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

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

 >
 >>There needs to be a way to tell hibernate to use the native key
 >>generator for a table. And the code needs to check for it.  Do you think
 >>its better to compare the class of the keygenerator?
 >>
 >
 >hhmmmmm instanceof sort of looks bad though in this case its perfectly
 >defensible. My suggestion was to have
 >
 > ClassPersister.isUsingNativeKeyGeneration()
 >
ok, i added a boolean to ClassPersister, and I init it with instanceof.
I'll also document it in the native id generator.

 >
 >
 >
 >>I will have to add two things to Dialect: one for the identity select,
 >>and one for the creation of the identity column.
 >>
 >
 >Thats all good. I'm not at all perturbed by that (anyway Dialect is an
 >abstract class, not an interface, so we can do more with it).
 >
One problem that i realized now is that the Classpersister is not aware
of the DatabaseDialect. The Database Dialect is only set when a schema
is generated. For the database native keys to work, it will be necessary
that this Property is set. I'm quite happy with it being a property,
because i want to use one mapping file for different databases.

One more thing: How can I run the unit tests? Is this documented somewhere?

regards
  chris

 >
 >
 >
 >_______________________________________________
 >Hibernate-devel mailing list
 >Hib...@li...
 >https://lists.sourceforge.net/lists/listinfo/hibernate-devel
 >
 >

Re: [Hibernate-devel] database native keys

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

> There needs to be a way to tell hibernate to use the native key
> generator for a table. And the code needs to check for it.  Do you think
> its better to compare the class of the keygenerator?

hhmmmmm instanceof sort of looks bad though in this case its perfectly
defensible. My suggestion was to have

 ClassPersister.isUsingNativeKeyGeneration()

or something. But then you would need to set that up in the first place
which would involve doing either an instanceof or equivalent anyway....
How about if we use instanceof in the constructor of ClassPersister
where its nice and hidden away and no-one will notice it ;)

I'm not quite joking; I'd prefer "expedient" things in any class other
than RelationalDatabaseSession. Yeah, I know I wouldn't be able to defend
this if pressed  .... whatever ..... just stick an instanceof wherever
you think is right.....

I'm rambling today....

> What? no blobs? :P
> how does postgres handle binary data then?

Very Badly.

http://www.postgresql.org/idocs/index.php?lo-interfaces.html

Actually there are large objects but theres some wierd way of using them
I don't understand....

Also theres a varbinary type, of course.


> I will have to add two things to Dialect: one for the identity select,
> and one for the creation of the identity column.

Thats all good. I'm not at all perturbed by that (anyway Dialect is an
abstract class, not an interface, so we can do more with it).

Re: [Hibernate-devel] Bug with Selection of Property of Value Type and ORDER BY

[Georg S. <ge...@sc...>]

On Tuesday 05 March 2002 15:37, you wrote:
> Thanks for that Georg. I'm sure theres no good reason why its
> disabled. Please check that fix in and if you get a chance, can you
> add something like it to the test suite.

Done.

Regards,
  Georg

Re: [Hibernate-devel] database native keys

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

Hi Gavin!

thanks for your feedback!

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

>Cool! Sounds great.
>
>>* Added a public boolean isNative function to the IDGenerator interface.
>>All old generators return false here, the NativeGenerator returns true.
>>
>
>I'm wondering if this is the best place for this flag. Can't see how its
>used but I would have been tempted to plonk it on ClassPersister instead.
>My reasoning is that there will only ever be that one single implementation
>of IDGenerator where it returns false. By adding the method to IDGenerator
>we force every future implementation of the interface to declare a method
>that does the exact same thing.
>
There needs to be a way to tell hibernate to use the native key 
generator for a table. And the code needs to check for it.  Do you think 
its better to compare the class of the keygenerator?

>Doesn't someone out there need BLOB support?? This can't be part of the
>"official" API because some priority target platforms (Postgres) don't
>have BLOBS yet. Still, I would happily distribute BLOBType with the rest
>of the project....
>
What? no blobs? :P
how does postgres handle binary data then?

>
>
>I think what I just did is called "going off on a tangent".
>
>Anyways my point was lets try and keep IDGenerator and Dialect as trivial
>as possible. If possible. Cool?
>

I will have to add two things to Dialect: one for the identity select, 
and one for the creation of the identity column.

Tell me what you think, and I'll go ahead :)

regards
 chris

Re: [Hibernate-devel] Bug with Selection of Property of Value Type and ORDER BY

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

Thanks for that Georg. I'm sure theres no good reason why its disabled.
Please check that fix in and if you get a chance, can you add something
like it to the test suite.

peace

Gavin

Re: [Hibernate-devel] database native keys

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

Cool! Sounds great.

> * Added a public boolean isNative function to the IDGenerator interface.
> All old generators return false here, the NativeGenerator returns true.

I'm wondering if this is the best place for this flag. Can't see how its
used but I would have been tempted to plonk it on ClassPersister instead.
My reasoning is that there will only ever be that one single implementation
of IDGenerator where it returns false. By adding the method to IDGenerator
we force every future implementation of the interface to declare a method
that does the exact same thing.

There are three places where hibernate is supposed to support
user-extension

* cirrus.hibernate.sql.Dialect
* cirrus.hibernate.id.IDGenerator
* cirrus.hibernate.type.Type

People have gone crazy adding new Dialects which is All Good. I had hoped
for a bit more action in the other areas.....

Now, Type has already got a little bit out of hand and will probably be
slightly refactored sometime soon (before 1.0). I notice no-one has taken
the plunge and tried to add new Types so far. This is probably an
indication that something is wrong. (Or maybe everyone is just so happy
with the existing Types.)

Doesn't someone out there need BLOB support?? This can't be part of the
"official" API because some priority target platforms (Postgres) don't
have BLOBS yet. Still, I would happily distribute BLOBType with the rest
of the project....

I think what I just did is called "going off on a tangent".

Anyways my point was lets try and keep IDGenerator and Dialect as trivial
as possible. If possible. Cool?

[Hibernate-devel] Bug with Selection of Property of Value Type and ORDER BY

[Georg S. <ge...@sc...>]

ORDER BY does not work with the selection of property of value type, 
e.g.:
SELECT many.one FROM many IN CLASS test.Many ORDER BY many.one.value
(many has a many-to-one mapping to one)

Hibernate generates the following SQL:
SELECT DISTINCT one2.one_key, one1.value FROM one one2, one one1, many 
many WHERE 1=1  and many.one_key = one2.one_key ORDER BY one1.value

without a join of one1.one_key and one2.one_key or many.one_key. After 
looking through the source I found a disabled call in 
cirrus.hibernate.query.OrderByParser, line 30. With the following 
change:

@@ -30,7 +30,7 @@ public class OrderByParser implements Pa
-                       //q.appendWhereToken( 
pathExpressionParser.getJoin() );
+                       q.appendWhereToken( 
pathExpressionParser.getWhereJoin() );

Hibernate generates the following (correct) SQL:
SELECT DISTINCT one2.one_key, one1.value FROM one one2, one one1, many 
many WHERE 1=1  and many.one_key = one1.one_key  and many.one_key = 
one2.one_key ORDER BY one1.value

I run the tests with this change and all went ok. Why is the the call 
disabled?
If nothing else brakes I will change this in cvs and add a test for 
ORDER BY.

Bye, Georg

Re: [Hibernate-devel] database native keys

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

Hi Gavin!

Thanks for the pointers. I implemented native key generation now for 
mssql server in a quite raw fashion, and I can send you the patches 
after some more tests.
What I did:
* Created A new key generator (NativeGenerator), and put it into the 
idgenerators map. This generator returns null as id.
* Added a public boolean isNative function to the IDGenerator interface. 
All old generators return false here, the NativeGenerator returns true.
* removed the id column from the insert if the idgen is native.
* RelationalDatabaseSession.save(Object object, Serializable id) now 
calls the insert instead of  creating a ScheduledInsert, but only if id 
== null
* ClassPersister.insert(insert(Serializable id, Object[] 
fields,SessionImplementor session) now returns the generated id as 
Serializable.

Whats still left to do is get the identity select from the 
DatabaseDialect, and modify the schema generation to generate identity 
columns.

regards
 chris

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

>>I was wondering how difficult it would be to support database native
>>keys in hibernate (i.e. indentity columns in sybase/mssql), or if theres
>>a reason why its not implemented atm in hibernate. If its really easy i
>>could take a look at implementing it ;)
>>
>
>It would be great if you could get this going. It would certainly be a
>great feature to have. I think the main difficulty would be this:
>
>1. Hibernate always delays executing SQL statements until a flush(), so you
>can't know what the generated key is until _after_ you execute the insert.
>2. Hibernate uses the key in its internal data structures (and in other
>ways) so its expecting to know the key _before_ you execute the insert.
>
>Fixing this *should* be as simple as deciding to execute the insert
>immediately for some classes (and sticking with the current behaviour for
>others).
>
>Have a look at:
>
>(1) RelationalDatabaseSession.save(Object object, Serializable id)
>(2) ClassPersister.insert(insert(Serializable id, Object[] fields,
>SessionImplementor session)
>
>These two methods do the work of
>(1)
>  * assigning an id,
>  * calling PersistentLifecycle.create(),
>  * copying the state of the object,
>  * nullifying references to transient objects (in the copied state),
>  * registering the object and its copied state in the sessions internal
>data structure,
>  * scheduling the actual insertion for later
>
>(2)
>  * actually executing the SQL insert
>
>The class ScheduledInsertion adds an indirection between save() and insert
>() that lets Hibernate execute the insertion "later". I suppose you would
>want to remove this indirection....
>
>Good Luck!
>
>
>

Re: [Hibernate-devel] database native keys

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

> I was wondering how difficult it would be to support database native
> keys in hibernate (i.e. indentity columns in sybase/mssql), or if theres
> a reason why its not implemented atm in hibernate. If its really easy i
> could take a look at implementing it ;)

It would be great if you could get this going. It would certainly be a
great feature to have. I think the main difficulty would be this:

1. Hibernate always delays executing SQL statements until a flush(), so you
can't know what the generated key is until _after_ you execute the insert.
2. Hibernate uses the key in its internal data structures (and in other
ways) so its expecting to know the key _before_ you execute the insert.

Fixing this *should* be as simple as deciding to execute the insert
immediately for some classes (and sticking with the current behaviour for
others).

Have a look at:

(1) RelationalDatabaseSession.save(Object object, Serializable id)
(2) ClassPersister.insert(insert(Serializable id, Object[] fields,
SessionImplementor session)

These two methods do the work of
(1)
  * assigning an id,
  * calling PersistentLifecycle.create(),
  * copying the state of the object,
  * nullifying references to transient objects (in the copied state),
  * registering the object and its copied state in the sessions internal
data structure,
  * scheduling the actual insertion for later

(2)
  * actually executing the SQL insert

The class ScheduledInsertion adds an indirection between save() and insert
() that lets Hibernate execute the insertion "later". I suppose you would
want to remove this indirection....

Good Luck!

[Hibernate-devel] database native keys

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

Hi All!

I was wondering how difficult it would be to support database native 
keys in hibernate (i.e. indentity columns in sybase/mssql), or if theres 
a reason why its not implemented atm in hibernate. If its really easy i 
could take a look at implementing it ;)

regards
 chris

Re: Re[2]: [Hibernate-devel] RE: Pessimistic locking?

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

> In databases with full versioning, I don't think the "probability of
> transaction failure is large," it can be quite the contrary, depending
> on how the database is being used.

cool. I understand this better now.

Re[2]: [Hibernate-devel] RE: Pessimistic locking?

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

> Now my understanding is that, contrary to Sybase and DB2, Oracle does not
> use read locks to implement serializable isolation. So you find out at
> transaction commit time that the transaction was unserializable, rather
> than having the transaction block halfway through. This does sound like
> optimistic locking to me. I think postgres might also work this way.

> P.S. I would personally be tempted to think of this as a misfeature of
> oracle since it means that with very-high-concurrency data and a
> high isolation level, the probability of transaction failure is
> large. Perhaps I'm wrong on this; there certainly are performance
> advantages to the non-blocking model.

It used to be (and should still be) that Postgress, and Interbase, use
versioning to support higher concurrency. The design is quite similar
to the caching algorithm I proposed (but it works in the database
because it is in control of the transaction!). Once a transaction
starts, all reads return versions of rows from the transaction start
time (at least in the atomic transaction case). This means that
transactions which only read never fail. So, report generators and
backup programs can run concurrently with other transactions and there
is no interference. Only two transactions which both write can
interfere with each other.

Clearly if two transactions attempt to write-lock the same row, one
will have to fail (or wait). So, select for update can make these
transactions fail faster, and is a good thing.

In databases with full versioning, I don't think the "probability of
transaction failure is large," it can be quite the contrary, depending
on how the database is being used.

e