hibernate-devel

Re: [Hibernate-devel] SQL Server 2000 questions

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

The one I have been using is JSQL from:

http://www.j-netdirect.com/

This particular driver seems to work beautifully.

I have just verified that Weblogic jDriver also works (with one very minor
test failure).

FreeTDS certainly does *not* work. I _think_ someone reported that

http://www.inetsoftware.de/

also does *not* work. (Havn't tried this myself)

The latest version of Microsoft's driver doesn't pass all tests, but it
does pass *some*. It might be almost possible to get it working, but I'm
not particularly optimistic. (If you want to try, you _must_ use the
SelectMethod=cursor JDBC connection parameter.)

Good Luck

Gavin

RE: [Hibernate-devel] SQL Server 2000 questions

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

> Don't know if/when you'll get this, but thought I'd send it while I go
off
> and look  into things.

> Are there instructions, or can you point me in the right direction, to
run
> the test suite against a particular JDBC driver / database? I want to run
it
> against SQL Server 2K w/ the MS JDBC driver just to see what I discover.

The class cirrus.hibernate.test.FooBarTest is executable. Run it with
"mssql" as a command line argument.

Hope thats enough to get you started. Any problems let me know.

peace

Gavin

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

Gavin,

Thanks for responding.

I was able to figure out how to run FooBarTest. After setting the proper
"SelectMethod=cursor" parameter in the URL, I was able to run a large number
of the tests. Here are a couple of the issues I encountered:

In testLoad there was a NPE, though the program kept running:

testLoad...
java.lang.NullPointerException
        at
cirrus.hibernate.impl.RelationalDatabaseSession$Key.hashCode(RelationalDatab
aseSession.java:183)
        at java.util.HashMap.hash(HashMap.java:250)
        at java.util.HashMap.get(HashMap.java:301)
        at
cirrus.hibernate.impl.RelationalDatabaseSession.save(RelationalDatabaseSessi
on.java:464)
        at
cirrus.hibernate.impl.RelationalDatabaseSession.insert(RelationalDatabaseSes
sion.java:445)
        at cirrus.hibernate.test.FooBarTest.testLoad(FooBarTest.java:178)
        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:1217)

In testQuery, there was this exception:

testQuery...
Exception in thread "main" 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:1217)
Caused by: java.lang.Exception: component query
        at cirrus.hibernate.test.TestCase.assertTrue(TestCase.java:66)
        at cirrus.hibernate.test.FooBarTest.testQuery(FooBarTest.java:323)
        ... 6 more

I couldn't quite figure out what was underlying this issue. You'll note from
the "... 6 more" line that this was under JDK 1.4. It was with the 0.9.8
release.

A couple of other comments, most of which you probably know:

1) The sybase dialect really isn't appropriate for SQL Server 2000. SS2K has
data types that a lot more directly map to the java.sql.Types (e.g. bit to
BIT, bigint to BIGINT, etc.).

2) In trying to workaround one problem, I had to change some hibernate code
(nothing permanent). The lack of a build facility meant I had to cobble
together a batch file to do that. A nice Ant script would be great (maybe I
missed something in the download).

3) This is more of a philosophical thing. I agree quite fully about the
reflection-based approach to mapping. However, I tend to think that the DB
should be the authority when it comes to the schema, not the app or a .xml
file. This is primarily because the things that one can specify about the
schema in, for example, Enterprise Manager start getting fairly
database-specific (constraints, triggers, etc.); and they aren't necessarily
important to represent in the .xml file. So I tend to start in the database
and try to take as much advantage as possible of its capabilities to
declaratively define the schema and the rules for enforcing data integrity.

Another point is that writing bean-style property methods on a class is
excruciatingly tedious. What I'm getting at is that I'd like to see a
generator facility to go from the schema to the .xml and from the .xml to
the skeleton of the bean classes. It wouldn't need to be a required
capability to use Hibernate, more of an optional facility like the current
schema generator.

Just one man's opinion...

Thanks again,

Donnie





> -----Original Message-----
> From: Gavin_King/Cirrus%CI...@ci...
> [mailto:Gavin_King/Cirrus%CI...@ci...]
> Sent: Saturday, April 13, 2002 9:12 PM
> To: Donnie Hale
> Cc: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>
>
>
> > Don't know if/when you'll get this, but thought I'd send it while I go
> off
> > and look  into things.
>
> > Are there instructions, or can you point me in the right direction, to
> run
> > the test suite against a particular JDBC driver / database? I
> want to run
> it
> > against SQL Server 2K w/ the MS JDBC driver just to see what I discover.
>
> The class cirrus.hibernate.test.FooBarTest is executable. Run it with
> "mssql" as a command line argument.
>
> Hope thats enough to get you started. Any problems let me know.
>
> peace
>
> Gavin
>
>

[Hibernate-devel] schema generation

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

Donnie Hale wrote:
> Another point is that writing bean-style property methods on a
> class is excruciatingly tedious.  What I'm getting at is that
> I'd like to see a generator facility to go from the schema to
> the .xml and from the .xml to the skeleton of the bean classes.
> It wouldn't need to be a required capability to use Hibernate,
> more of an optional facility like the current schema generator.

I'll second that.  I've just begun using Hibernate (I'm very impressed with
it, BTW!) and this is one of the first requirements I ran into.

In the first project I'm using it on, what I'm doing to deal with the above
issue is a little perverse, but it's working for my purposes so far: I wrote
some code to generate the bean skeletons from my database schema.  This was
pretty simple to do given that I was able to make assumptions about this
particular system and database, and even naming conventions, in order to
come up with a decent set of bean skeletons.  I then used Hibernate's
MappingByReflection class to generate a Hibernate XML mapping.  This has
worked pretty well for me as a starting point, but it's by no means general
or complete.

A full set round-trip tools that can propagate changes from the classes to
the mapping to the database (in arbitrary sequence :) would be great.  The
easiest to implement is probably the one which goes from Hibernate's XML to
bean skeletons - that's pretty trivial.  If such a tool doesn't already
exist and no-one gets to it before me, I'll probably implement that.

> I tend to think that the DB should be the authority when it comes to the
schema

I'm guessing most Hibernate users are using their Java classes as the master
source of schema information, otherwise the tools we're looking for would
already exist...  ;)

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

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

hi donnie

get the cvs version.  it has an ant build script that enables u to
compile, javadoc, test, etc.

gavin, if hibernate is sticking with the one distribution (classes and
source together) then i think the user should be able change the code
and rebuild the distribution easily.    to achieve this the ant script
should be included and possibly the libs.  if u wanted to tidy this
aspect of the project up using ant as the one build tool, i can
certainly give u a hand.  also, the java source is currently included in
the jar.

on your philosophical topic (and each to his/her own here), i work the
opposite way (even after being a dba somewhere in the dim, dark past).
i find it much more intuitive and less time consuming to work at the
object level, since that is what all my code that implements the
application's logic is directly manipulating.  how those objects are
persisted is then not the most important thing.  having said that, i do
go and check/tweak the schema to ensure integrity and performance.  just
my thoughts, like i said, each to there own.

i agree that writing bean-style property methods is tedious, but it is a
task than can be fairly easily automated.

brad

> -----Original Message-----
> From: Donnie Hale [mailto:do...@ha...]
> Sent: Monday, 15 April 2002 5:13 AM
> To: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>=20
>=20
> Gavin,
>=20
> Thanks for responding.
>=20
> I was able to figure out how to run FooBarTest. After setting=20
> the proper
> "SelectMethod=3Dcursor" parameter in the URL, I was able to run=20
> a large number
> of the tests. Here are a couple of the issues I encountered:
>=20
> In testLoad there was a NPE, though the program kept running:
>=20
> testLoad...
> java.lang.NullPointerException
>         at
> cirrus.hibernate.impl.RelationalDatabaseSession$Key.hashCode(R
> elationalDatab
> aseSession.java:183)
>         at java.util.HashMap.hash(HashMap.java:250)
>         at java.util.HashMap.get(HashMap.java:301)
>         at
> cirrus.hibernate.impl.RelationalDatabaseSession.save(Relationa
> lDatabaseSessi
> on.java:464)
>         at
> cirrus.hibernate.impl.RelationalDatabaseSession.insert(Relatio
> nalDatabaseSes
> sion.java:445)
>         at=20
> cirrus.hibernate.test.FooBarTest.testLoad(FooBarTest.java:178)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39
> )
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl
> .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:1217)
>=20
> In testQuery, there was this exception:
>=20
> testQuery...
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39
> )
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl
> .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:1217)
> Caused by: java.lang.Exception: component query
>         at cirrus.hibernate.test.TestCase.assertTrue(TestCase.java:66)
>         at=20
> cirrus.hibernate.test.FooBarTest.testQuery(FooBarTest.java:323)
>         ... 6 more
>=20
> I couldn't quite figure out what was underlying this issue.=20
> You'll note from
> the "... 6 more" line that this was under JDK 1.4. It was=20
> with the 0.9.8
> release.
>=20
> A couple of other comments, most of which you probably know:
>=20
> 1) The sybase dialect really isn't appropriate for SQL Server=20
> 2000. SS2K has
> data types that a lot more directly map to the java.sql.Types=20
> (e.g. bit to
> BIT, bigint to BIGINT, etc.).
>=20
> 2) In trying to workaround one problem, I had to change some=20
> hibernate code
> (nothing permanent). The lack of a build facility meant I had=20
> to cobble


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

RE: [Hibernate-devel] SQL Server 2000 questions

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

> I was able to figure out how to run FooBarTest. After setting the proper
> "SelectMethod=cursor" parameter in the URL, I was able to run a large
number
> of the tests. Here are a couple of the issues I encountered:

Sorry, I should have mentioned the SelectMethod=cursor bit. Its very
important.

> In testLoad there was a NPE, though the program kept running:

Dont worry, the NPE is intended as a test.

> In testQuery, there was this exception:

> testQuery...
> Exception in thread "main" java.lang.reflect.InvocationTargetException
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[snip]

>I couldn't quite figure out what was underlying this issue. You'll note
from
>the "... 6 more" line that this was under JDK 1.4. It was with the 0.9.8
>release.

Urrghhh thats an unhelpful looking stacktrace. I might mess with TestCase
to unwrap the wrapped exception. Been meaning to do that for a while.
Alternatively I could switch to JUnit which everyone else seems to be in
favor of.....

I have looked at this problem in the past but I forget exactly what the
root cause was. I did verify that it was something I couldn't easily
fix....

It would be very nice if we can establish exactly which subset of
hibernate's functionality is working using the MS driver. It might turn out
to be a large enough subset for some people's requirements.

> A couple of other comments, most of which you probably know:

> 1) The sybase dialect really isn't appropriate for SQL Server 2000. SS2K
has
> data types that a lot more directly map to the java.sql.Types (e.g. bit
to
> BIT, bigint to BIGINT, etc.).

Thankyou for letting me know this. Would you like to write an MSSQLDialect
for us? You seem to know the platform much better than me.

> 2) In trying to workaround one problem, I had to change some hibernate
code
> (nothing permanent). The lack of a build facility meant I had to cobble
> together a batch file to do that. A nice Ant script would be great (maybe
I
> missed something in the download).

Try checking out the latest CVS. (There are also some improvements/fixes in
there that I really should have released weeks ago - been so busy)

> 3) This is more of a philosophical thing. I agree quite fully about the
> reflection-based approach to mapping. However, I tend to think that the
DB
> should be the authority when it comes to the schema, not the app or a
.xml
> file. This is primarily because the things that one can specify about the
> schema in, for example, Enterprise Manager start getting fairly
> database-specific (constraints, triggers, etc.); and they aren't
necessarily
> important to represent in the .xml file. So I tend to start in the
database
> and try to take as much advantage as possible of its capabilities to
> declaratively define the schema and the rules for enforcing data
integrity.

Can you give me a better idea of exactly how you would divide
responsibility here. It sort of seems to me that _schemas_ are easy things
to keep in the database but _mappings_ not so easy.... One intended
approach is to define all schemas on the DB and use the mapping file as a
map _only_. You dont need to use the schema generation tool. I'm very open
to new ideas on all this....

> Another point is that writing bean-style property methods on a class is
> excruciatingly tedious.

Aaahhhh ... being an IDE-user I probably underestimate the pain in this for
some people. You know, it would be about an hours work to let hibernate use
also instance variables directly. Would anyone like this?

> What I'm getting at is that I'd like to see a
> generator facility to go from the schema to the .xml and from the .xml to
> the skeleton of the bean classes. It wouldn't need to be a required
> capability to use Hibernate, more of an optional facility like the
current
> schema generator.

That would be nice. If anyone wants to contribute something like that we
should certainly include it.

> Just one man's opinion...

Which is very welcome :)

peace

Gavin




> -----Original Message-----
> From: Gavin_King/Cirrus%CI...@ci...
> [mailto:Gavin_King/Cirrus%CI...@ci...]
> Sent: Saturday, April 13, 2002 9:12 PM
> To: Donnie Hale
> Cc: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>
>
>
> > Don't know if/when you'll get this, but thought I'd send it while I go
> off
> > and look  into things.
>
> > Are there instructions, or can you point me in the right direction, to
> run
> > the test suite against a particular JDBC driver / database? I
> want to run
> it
> > against SQL Server 2K w/ the MS JDBC driver just to see what I
discover.
>
> The class cirrus.hibernate.test.FooBarTest is executable. Run it with
> "mssql" as a command line argument.
>
> Hope thats enough to get you started. Any problems let me know.
>
> peace
>
> Gavin
>
>

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

Thanks for the responses - it's appreciated. I've combined some points from
various posts into this for simplicity purposes. Sorry for the delay getting
back to this...

>
> Sorry, I should have mentioned the SelectMethod=cursor bit. Its very
> important.
>

I think that this is mentioned someplace, but I wasn't sure how to set it.
The MS newsgroup for the JDBC driver was very helpful.

>
> Dont worry, the NPE is intended as a test.
>

Since it went on, I thought it might be. Just wanted to be sure...


> > In testQuery, there was this exception:
>
> > testQuery...
> > Exception in thread "main" java.lang.reflect.InvocationTargetException
> >        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> [snip]
>
> >I couldn't quite figure out what was underlying this issue. You'll note
> from
> >the "... 6 more" line that this was under JDK 1.4. It was with the 0.9.8
> >release.
>
> Urrghhh thats an unhelpful looking stacktrace. I might mess with TestCase
> to unwrap the wrapped exception. Been meaning to do that for a while.
> Alternatively I could switch to JUnit which everyone else seems to be in
> favor of.....
>
> I have looked at this problem in the past but I forget exactly what the
> root cause was. I did verify that it was something I couldn't easily
> fix....
>

Does anyone know if there's a system property or some such for JDK 1.4 that
will keep it from truncating the stack traces like that?

> It would be very nice if we can establish exactly which subset of
> hibernate's functionality is working using the MS driver. It
> might turn out
> to be a large enough subset for some people's requirements.

Well however far it gets before testQuery works fine, apparently. So I
suppose that if no other tests depend on testQuery, we could comment out
that method and run things again.

>
> Thankyou for letting me know this. Would you like to write an MSSQLDialect
> for us? You seem to know the platform much better than me.
>

I'd hoped to do this tonight, but I ended up doing garage work when I got
home. :( As I indicated, SS2K has pretty direct mappings for all the
java.sql.Types, so those can be used directly. I'm curious how to handle the
things like SS2K's "money" and "smallmoney" types, etc. Those are useful at
the DB level. There needs to be mapping both ways for things like that, I
think.

>
> Can you give me a better idea of exactly how you would divide
> responsibility here. It sort of seems to me that _schemas_ are easy things
> to keep in the database but _mappings_ not so easy.... One intended
> approach is to define all schemas on the DB and use the mapping file as a
> map _only_. You dont need to use the schema generation tool. I'm very open
> to new ideas on all this....
>

Today I started a new project, and I used SQL Server Enterprise Manager to
define the schema. I use it because it's very easy, it provides access to
all the esoteric things like check constraints, index-based constraints,
default values, formulas, etc. Once that's done I can generate a SQL script
that will recreate the thing on any database whenever I need to. I find that
a much more complete approach. Someone in another message mentioned
generating the schema from the map and then massaging the schema w/ the
db-specific tools. If the schema changes are of any substance, you'll end up
dropping the tables and then you have to go back in and re-massage the
schema. That's why I think the db-specific tools are the best starting point
for the in-db schema.

>>
[from Brad Clow, and responding some to others' comments about instance
variables and philosophical approach]i agree that writing bean-style
property methods is tedious, but it is a
task than can be fairly easily automated.
<<

First, if people haven't seen it yet, check out Martin Fowler's wonderful
work at: http://martinfowler.com/isa/index.html. I tend to prefer an
approach with layers as follows:

(database itself) ->
data access objects (DAOs) ->
data transfer objects (DTOs) ->
business domain objects (BOs) ->
coarse-grained service interface

The DAOs have the actual SQL, prepare statements, perform selects and deal
w/ result sets, etc. The DTOs (called by many "value objects", but I'm using
Fowler's terminology) are Java beans at their most basic - they have
attributes and setters/getters for each column in the table/view to which
they correspond. Business objects have the logic and only expose operation
methods, not getters/setters unless absolutely required to meet business
logic requirements (think: if it's not in the sequence diagram for the
business logic implementation, it doesn't get written :). The BOs  "have-a"
DTO of the corresponding type to hold the actual data (so it doesn't have to
be copied all over the place). DTOs are important, in my opinion, because
the values frequently have to be passed "over-the-wire" between layers, and
I don't want the business objects being accessible to those other layers.

With that as a background, Hibernate seems to be more aligned with putting
the data for a row directly in the business object. Many people prefer that,
and I can sympathize with them. However, it's not my preferred approach. I
like the data in the DTOs and the business objects being focused on the
business operations that must be fulfilled for a particular type of business
entity.

The good thing is that it should be really easy to generate DTOs, because
all that's needed are attributes of the right type and setter/getter
methods. The only tricky parts would seem to be: construction based on a
constructor that takes args (the PK being the way I like it); and making the
accessor methods for boolean properties have the "isWhatever" form versus
the "getWhatever" or "getIsWhatever".

Someone's going to bring up the issue of relationships, and with the design
pattern I prefer, it's definitely an issue. The DTOs will have the foreign
key for a related table, but not a reference to an instance of the
related/parent DTO. All I can say is that I prefer this pattern enough to
deal w/ relationship management myself at the business object level.

FWIW...

Donnie

RE: [Hibernate-devel] SQL Server 2000 questions

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

Donnie Hale wrote:
> With that as a background, Hibernate seems to be more aligned with putting
> the data for a row directly in the business object. Many people
> prefer that, and I can sympathize with them. However, it's not
> my preferred approach. I like the data in the DTOs and the
> business objects being focused on the business operations
> that must be fulfilled for a particular type of business
> entity.

What I've been doing (pre-Hibernate) is to have the business objects inherit
from their corresponding DTOs.  This allows the business objects to
implicitly access the data they need, without reference to an external
object.  It also allows you to easily marshal a DTO and send it elsewhere,
without business logic, if you want/need to.  Finally, it handles
relationship issues better, IMO.

This approach ought to work well with Hibernate, and is what I'm pursuing.
But any pattern which maintains DTO-like objects separately from the classes
containing business logic ought to be easier for automated tools to deal
with, especially in early, less-sophisticated incarnations, because it may
allow them to completely recreate the DTOs when the source schema changes.

> All I can say is that I prefer this pattern enough to
> deal w/ relationship management myself at the business object level.

I'm curious what disadvantage you see to the approach I've described.  I
suppose the fact that application objects would inherit a public set of
getters/setters - more than they might need to expose - might be considered
a disadvantage by some.  If that were really an issue, it might be dealt
with by having the DTOs have protected getters/setters, and if the business
objects want to expose any of them, it would define public versions.  Being
able to send independent DTOs elsewhere would then need to be dealt with,
but that could be done too, in a variety of ways.

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

Anton,

You know, I should have considered that approach. Another developer just
recently used something quite similar on a project I was on - full-blown
business objects, which had relationships and logic, were derived from
"summary" objects which had the data. He found it worked quite well, and
it's something I should have recalled. The only downside to that approach is
that, for the DTOs to be useful on the other side of the wire, the
setters/getters have to be public. Which means that they're public on the
business object as well, and I don't really like that. Too procedural, not
good for abstraction and encapsulation.

What I meant to put in my prior message but forgot is that a lot of the
tools along these lines try to be all things to all people. That's
commendable, but it also makes some of them unapproachable. I'd much prefer
a tool that enforced "best practices" for design patterns (especially if
they're the best practices I agree with ;); and I think Hibernate has a
chance to do that or at least get close by being fairly thin and
lightweight. At present it's still pretty approachable.

What would be nice with your pattern is if Hibernate allowed you to define
and use the DTOs for just row data but to generate the relationships at the
business object level. That would get very close to what I like. A business
object "is-a" DTO; it has references to other BOs or sets of BOs to which it
is related; it has instances of DTOs which are dependent objects (no
corresponding BO). Appropriate references to typesafe enum instances for
codes and simple lookup values. Then I'd be done... :)

Take care,

Donnie


> -----Original Message-----
> From: Anton van Straaten [mailto:an...@ap...]
> Sent: Monday, April 15, 2002 10:36 PM
> To: Donnie Hale; hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>
>
> Donnie Hale wrote:
> > With that as a background, Hibernate seems to be more aligned
> with putting
> > the data for a row directly in the business object. Many people
> > prefer that, and I can sympathize with them. However, it's not
> > my preferred approach. I like the data in the DTOs and the
> > business objects being focused on the business operations
> > that must be fulfilled for a particular type of business
> > entity.
>
> What I've been doing (pre-Hibernate) is to have the business
> objects inherit
> from their corresponding DTOs.  This allows the business objects to
> implicitly access the data they need, without reference to an external
> object.  It also allows you to easily marshal a DTO and send it elsewhere,
> without business logic, if you want/need to.  Finally, it handles
> relationship issues better, IMO.
>
> This approach ought to work well with Hibernate, and is what I'm pursuing.
> But any pattern which maintains DTO-like objects separately from
> the classes
> containing business logic ought to be easier for automated tools to deal
> with, especially in early, less-sophisticated incarnations, because it may
> allow them to completely recreate the DTOs when the source schema changes.
>
> > All I can say is that I prefer this pattern enough to
> > deal w/ relationship management myself at the business object level.
>
> I'm curious what disadvantage you see to the approach I've described.  I
> suppose the fact that application objects would inherit a public set of
> getters/setters - more than they might need to expose - might be
> considered
> a disadvantage by some.  If that were really an issue, it might be dealt
> with by having the DTOs have protected getters/setters, and if
> the business
> objects want to expose any of them, it would define public
> versions.  Being
> able to send independent DTOs elsewhere would then need to be dealt with,
> but that could be done too, in a variety of ways.
>
> Anton
>
>

RE: [Hibernate-devel] SQL Server 2000 questions

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

Donnie,

Thanks for the feedback, it's helping me clarify my thinking on this.

> The only downside to that approach is
> that, for the DTOs to be useful on the other side of the wire, the
> setters/getters have to be public. Which means that they're public
> on the business object as well, and I don't really like that.
> Too procedural, not good for abstraction and encapsulation.

How about this: define business object interfaces which your business
objects implement.  Clients of the business objects use these interfaces.
This would prevent clients from having access to DTO property methods
through the business objects, except by violating protocol and bypassing the
interfaces.

Using interfaces like this clearly documents and helps enforce which aspects
of the business objects are supposed to be public, which achieves the aspect
of this that I find most important.  But if you're set on actually enforcing
restrictions on getter/setter access through the business objects, you could
discourage or prevent such violations by appropriate use of factories for
the business objects, and protected constructors.

> What I meant to put in my prior message but forgot is that a lot
> of the tools along these lines try to be all things to all people.
> That's commendable, but it also makes some of them unapproachable.
> I'd much prefer a tool that enforced "best practices" for design
> patterns (especially if they're the best practices I agree with ;);
> and I think Hibernate has a chance to do that or at least get close
> by being fairly thin and lightweight. At present it's still pretty
> approachable.

I agree, and I was saying something along these lines in a reply to Gavin
last night.  I'm impressed by what I've seen so far.

> What would be nice with your pattern is if Hibernate allowed you to
> define and use the DTOs for just row data but to generate the
> relationships at the business object level. That would get very
> close to what I like. A business object "is-a" DTO; it has
> references to other BOs or sets of BOs to which it is related;
> it has instances of DTOs which are dependent objects (no
> corresponding BO). Appropriate references to typesafe enum instances
> for codes and simple lookup values. Then I'd be done... :)

Given Hibernate's use of getters/setters to populate the data, I don't see
why something pretty close to this couldn't be done fairly easily.  Here's
an outline:

First, use the approach I described above, with DTOs being parents of the
business objects, with public getters/setters.  Use interfaces for the BOs
if you want to control and better document access to the getters/setters.

Now, have Hibernate populate and persist the data via the BOs, not via the
DTOs.  Hibernate should use the getter/setter methods it's told about,
whether they're defined in the BO or inherited from its parent, the DTO.
This ought to allow you to split the basic instance/row data from the
relationships, exactly the way you want.

You ought to be able to hand-write a system right now that used Hibernate
like this, so Hibernate itself wouldn't need to change a bit - once again
demonstrating the power of a well-designed "lightweight" layer.  To make
this a bit more automatic, the schema management tools we've been talking
about could generate and later update the appropriate classes, although that
would go beyond the level of sophistication I was personally planning to get
into.  Still, I'll keep it in mind, since I'm working on some of this kind
of thing right now...

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

First - I'm getting double responses from Anton and Gavin. FWIW...

See below.

>
> How about this: define business object interfaces which your business
> objects implement.  Clients of the business objects use these interfaces.
> This would prevent clients from having access to DTO property methods
> through the business objects, except by violating protocol and
> bypassing the
> interfaces.
>

I've been thinking along those lines, except using abstrast base classes for
the BOs which "have-a" DTO and other relationships but which must be
extended for the concrete class. My ideas is to generate the DTO and the
abstract BO and then have the developer write the concrete BO. That way
regeneration can happen at any time w/o the worry of losing custom code that
had been written in the BO. Obviously, if there are substantive changes to
the DTO or abstract BO, then the concrete BO has to change; but it lets the
developer focus on that.

That's how my thinking has refined overnight.

>
>
> Given Hibernate's use of getters/setters to populate the data, I don't see
> why something pretty close to this couldn't be done fairly easily.  Here's
> an outline:
>

FWIW, I wrote a DTO-generator for the project I'm working on today. I'm not
at liberty to share it, unfortunately. Since I can't use Hibernate (SQL
Server 2K support via MS driver isn't complete yet), I wrote my own map file
format. It goes straight from the DB schema (tables or views) to Java DTO
code. I use Jakarta's commons-digester to read the map file and Velocity to
define the .java file template.

My main point is just that I wrote this in a day, so it's not a Herculean
effort.

Summarizing what I personally would like to see:

- a way to make the schema as it is in the database the authoritative
reference of the schema
- a way to generate DTOs from that schema, the DTOs only having a row's
column data - no relationships
- a way to generate the abstract BOs which "have-a" DTO of the corresonding
type along with all the appropriate relationships to other abstract BOs (a
question comes to mind there...), contained/dependent objects, etc.

A side-effect of this concept would be that the .xml file would be used at
generation time as well as runtime.

Take care,

Donnie

RE: [Hibernate-devel] SQL Server 2000 questions

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

> First - I'm getting double responses from Anton and Gavin. FWIW...

I'll be more careful - it comes from hitting "Reply All" on messages from
some mailing lists (majordomo?)

> Since I can't use Hibernate (SQL Server 2K support via MS driver isn't
> complete yet)

Not sure what the issues with MS driver are, but I've had good success with
the commercial driver JTurbo
(http://www.newatlanta.com/products/jturbo/index.jsp).  We initially
evaluated a slew of JDBC drivers for MS databases (SQL 6.5, 7.0, and 2000),
and found all sort of compatibility problems.  JTurbo was one of the few
that didn't have any problems that we could find, and was reasonably priced.
We also had pretty good success with the open source JDBC driver from the
FreeTDS project (http://www.freetds.org/software.html), but there was a
compatibility problem with SQL 6.5 at the time we tested.

> FWIW, I wrote a DTO-generator for the project I'm working on
> today.
...
> It goes straight from the DB schema (tables or views) to Java DTO
> code. I use Jakarta's commons-digester to read the map file and
> Velocity to define the .java file template.
>
> My main point is just that I wrote this in a day, so it's not a Herculean
> effort.

Great.  Perhaps the various different object architecture philosophies being
discussed can be handled using a set of classes and interfaces that can be
mixed and matched to generate classes according to taste.  For example,
whether the "master" schema info comes from the database, the Hibernate
mapping file, the beans themselves, or some other custom schema/mapping
file, it could all be made accessible through the same set of interfaces, so
that code which processes it wouldn't have to care where it came from.

Using something like Velocity, how that data is mapped to the DTOs and BOs
would also be very customizable.  Now all we need is an open version of all
this...  As I said, I'll do some of this myself if I'm not preempted, but I
haven't gotten to that point yet.  I'm interested to see Brad Clow's
generator, too.

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

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

> gavin, if hibernate is sticking with the one distribution (classes and
> source together) then i think the user should be able change the code
> and rebuild the distribution easily.    to achieve this the ant script
> should be included and possibly the libs.  if u wanted to tidy this
> aspect of the project up using ant as the one build tool, i can
> certainly give u a hand.  also, the java source is currently included in
> the jar.

building distributions is a hassle for me at the moment. Any help would be
very appreciated. And your suggestions are quite correct, of course.

> i agree that writing bean-style property methods is tedious, but it is a
> task than can be fairly easily automated.

Im using eclipse so its trivial. I really like the whole idea of decoupling
the persistent representation from the internal implementation. But I guess
its a matter of preference, so since theres no difficulty implemention
instance variable access, why not allow it?

RE: [Hibernate-devel] SQL Server 2000 questions

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

> > i agree that writing bean-style property methods is tedious, but it is a
> > task than can be fairly easily automated.
>
> Im using eclipse so its trivial.

I'm using Eclipse too, but it doesn't automate the creation of a large
number of beans from an existing database schema - does it?

> I really like the whole idea of decoupling
> the persistent representation from the internal implementation.

Me too.

> But I guess its a matter of preference

Don't give up your principles so easily!  ;)

> so since theres no difficulty implemention
> instance variable access, why not allow it?

My question would be: why allow it?

The issue for me isn't Hibernate's reliance on setters/getters - it's really
a more general concern, which is that if schema and mapping information is
stored in three different places, then synchronizing them could become
tedious, and error prone.

I'm speaking theoretically because I haven't used Hibernate enough to know
how important this might be in practice.  I realize that if you rely on the
beans as the central source for schema info, and can rely on
MappingByReflection to get the mapping you want, then the problem I'm
thinking of wouldn't exist.  However, with an existing database, it looks to
me as though it may not be that easy.  So I'm looking at dealing with manual
edits to the mapping XML, then synchronizing the beans with that, and
synchronizing changes in the database too.

Supporting instance variable access slightly reduces the number of places
that are affected by schema changes, but as has been mentioned, property
methods are easily automated, but the basic synchronization issue still
exists.  Besides, instance variable access would allow users to use non-bean
classes, but that only seems to encourage the writing of bad code - what's
the real advantage?

So I'm saying that the requirement raised by Donnie - which I think I
share - doesn't seem to really be solved by adding instance variable
support.  It seems to me that we haven't heard any really good arguments for
doing that.  (Course, I've only been subscribed to the list for 6 messages,
so add salt to taste... ;)

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

I'm pretty handy w/ Ant these days. If I can get the current environment
(maybe directly from CVS), I can look and see where things stand.

No promises, as I'm really swamped; plus this is mid-soccer season for my
boys. ;)

Donnie


> -----Original Message-----
> From: hib...@li...
> [mailto:hib...@li...]On Behalf Of
> Gavin_King/Cirrus%CI...@ci...
> Sent: Sunday, April 14, 2002 9:58 PM
> To: Brad Clow
> Cc: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>
>
>
>
> > gavin, if hibernate is sticking with the one distribution (classes and
> > source together) then i think the user should be able change the code
> > and rebuild the distribution easily.    to achieve this the ant script
> > should be included and possibly the libs.  if u wanted to tidy this
> > aspect of the project up using ant as the one build tool, i can
> > certainly give u a hand.  also, the java source is currently included in
> > the jar.
>
> building distributions is a hassle for me at the moment. Any help would be
> very appreciated. And your suggestions are quite correct, of course.
>
> > i agree that writing bean-style property methods is tedious, but it is a
> > task than can be fairly easily automated.
>
> Im using eclipse so its trivial. I really like the whole idea of
> decoupling
> the persistent representation from the internal implementation.
> But I guess
> its a matter of preference, so since theres no difficulty implemention
> instance variable access, why not allow it?
>
>
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>

RE: [Hibernate-devel] SQL Server 2000 questions

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

>  I'm saying that the requirement raised by Donnie - which I think I
> share - doesn't seem to really be solved by adding instance variable
> support.

Sorry, I may have given the impression I was missing the main point, which
is that people want to be able to do "bottom-up" style development as well
as "top-down" style. I fully understand the importance of this. But the
comment about generating properties being tedious got me thinking
tangentially about people using vi or emacs or something.....

But yeah, support for instance variable access never went in so far, simply
because it seemed like it would support a "worse" coding style. Now I'm
sounding real indecisive, huh? :)

RE: [Hibernate-devel] SQL Server 2000 questions

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

> But yeah, support for instance variable access never went in so
> far, simply because it seemed like it would support a "worse"
> coding style. Now I'm sounding real indecisive, huh? :)

When in doubt, procrastinate?  :)

To add a decision factor: if it could be added as a feature without any
cost, maybe some people would find that useful (although not me).  But even
if it only takes an hour of your time to implement, there are other costs:
documenting it, explaining why it shouldn't really be used, adding choices
which the user needs to understand and take into consideration.  Choice is
good if it provides important flexibility, but in this case it seems like it
would fall more on the side of gratuitous bloat.

BTW, I realize my argument may seem overly impassioned for an arguably minor
issue, and if you add the feature anyway, I won't really mind.  But when I
said "don't give up your principles so easily", I was thinking of one of the
features which attracted me to Hibernate in the first place: it seems to
have almost everything I need, and very little I don't, and it works the way
I expect it to.  I don't get the same feeling when I use EJB frameworks, for
example - which is why I avoid them when I can.  Limiting user choice can be
a good thing...

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

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

thanx for the link to martin's work, i will check that out when i can.

we use a layered approach similar to the one u have outlined.  i have
not found that hibernate is more aligned with putting data directly into
the BOs (using terminology below here).  the way we have approached the
architecture is:

DAOs: a mixture of hibernate itself and our own classes (that contain
the queries, so they are not spread all over the application).
DTOs: classes that hibernate maps to
BOs: stateless session ejbs (or just normal classes) that expose the
functions/services of the application.

in our case i c hibernate aligned more with the DTOs.

brad


> -----Original Message-----
> From: Donnie Hale [mailto:do...@ha...]
> Sent: Tuesday, 16 April 2002 11:48 AM
> To: hib...@li...
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>=20
<snip/>=20
> Today I started a new project, and I used SQL Server=20
> Enterprise Manager to
> define the schema. I use it because it's very easy, it=20
> provides access to
> all the esoteric things like check constraints, index-based=20
> constraints,
> default values, formulas, etc. Once that's done I can=20
> generate a SQL script
> that will recreate the thing on any database whenever I need=20
> to. I find that
> a much more complete approach. Someone in another message mentioned
> generating the schema from the map and then massaging the=20
> schema w/ the
> db-specific tools. If the schema changes are of any=20
> substance, you'll end up
> dropping the tables and then you have to go back in and re-massage the
> schema. That's why I think the db-specific tools are the best=20
> starting point
> for the in-db schema.
>=20
> >>
> [from Brad Clow, and responding some to others' comments=20
> about instance
> variables and philosophical approach]i agree that writing bean-style
> property methods is tedious, but it is a
> task than can be fairly easily automated.
> <<
>=20
> First, if people haven't seen it yet, check out Martin=20
> Fowler's wonderful
> work at: http://martinfowler.com/isa/index.html. I tend to prefer an
> approach with layers as follows:
>=20
> (database itself) ->
> data access objects (DAOs) ->
> data transfer objects (DTOs) ->
> business domain objects (BOs) ->
> coarse-grained service interface
>=20
> The DAOs have the actual SQL, prepare statements, perform=20
> selects and deal
> w/ result sets, etc. The DTOs (called by many "value=20
> objects", but I'm using
> Fowler's terminology) are Java beans at their most basic - they have
> attributes and setters/getters for each column in the=20
> table/view to which
> they correspond. Business objects have the logic and only=20
> expose operation
> methods, not getters/setters unless absolutely required to=20
> meet business
> logic requirements (think: if it's not in the sequence diagram for the
> business logic implementation, it doesn't get written :). The=20
> BOs  "have-a"
> DTO of the corresponding type to hold the actual data (so it=20
> doesn't have to
> be copied all over the place). DTOs are important, in my=20
> opinion, because
> the values frequently have to be passed "over-the-wire"=20
> between layers, and
> I don't want the business objects being accessible to those=20
> other layers.
>=20
> With that as a background, Hibernate seems to be more aligned=20
> with putting
> the data for a row directly in the business object. Many=20
> people prefer that,
> and I can sympathize with them. However, it's not my=20
> preferred approach. I
> like the data in the DTOs and the business objects being=20
> focused on the
> business operations that must be fulfilled for a particular=20
> type of business
> entity.
>=20
> The good thing is that it should be really easy to generate=20
> DTOs, because
> all that's needed are attributes of the right type and setter/getter
> methods. The only tricky parts would seem to be: construction=20
> based on a
> constructor that takes args (the PK being the way I like it);=20
> and making the
> accessor methods for boolean properties have the "isWhatever"=20
> form versus
> the "getWhatever" or "getIsWhatever".
>=20
> Someone's going to bring up the issue of relationships, and=20
> with the design
> pattern I prefer, it's definitely an issue. The DTOs will=20
> have the foreign
> key for a related table, but not a reference to an instance of the
> related/parent DTO. All I can say is that I prefer this=20
> pattern enough to
> deal w/ relationship management myself at the business object level.
>=20
> FWIW...
>=20
> Donnie
>=20
>=20
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>=20

RE: [Hibernate-devel] SQL Server 2000 questions

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

agreed, the relationships (like most things) could get u into
performance trouble.  we deal with this by making relationships
one-directional where possible and there is also the lazy loading
option.

i find having the relationships in the DTOs useful as it enables the
DTOs to be the *real* data model, rather than the database.  for me, it
is easier to model a business problem as an object model rather than a
relational model as u get easy inheritence, etc.  for us this translates
to much more agile development/maintenance process.  of course u get
back to the old trade-off of convenience/speed vs performance.

brad

> -----Original Message-----
> From: Donnie Hale [mailto:do...@ha...]
> Sent: Wednesday, 17 April 2002 11:09 AM
> To: Brad Clow
> Subject: RE: [Hibernate-devel] SQL Server 2000 questions
>=20
>=20
> See below.
>=20
> >
> > we use a layered approach similar to the one u have=20
> outlined.  i have
> > not found that hibernate is more aligned with putting data=20
> directly into
> > the BOs (using terminology below here).  the way we have=20
> approached the
> > architecture is:
> >
> > DAOs: a mixture of hibernate itself and our own classes=20
> (that contain
> > the queries, so they are not spread all over the application).
> > DTOs: classes that hibernate maps to
> > BOs: stateless session ejbs (or just normal classes) that expose the
> > functions/services of the application.
> >
> > in our case i c hibernate aligned more with the DTOs.
> >
>=20
> As far as setters/getters go, I agree. But Hibernate expects the
> relationship stuff (so far as I can tell) to be in the same=20
> class w/ the
> basic column properties. So now a DTO has references to=20
> things all over the
> place (potentially). At that point, using the DTO as a=20
> mechanism to transfer
> data between layers / "over-the-wire" becomes difficult or at least
> potentially more expensive than one may want.
>=20
> I appreciate all the give-and-take in this thread...
>=20
> Donnie
>=20
>=20

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

>
> i find having the relationships in the DTOs useful as it enables the
> DTOs to be the *real* data model, rather than the database.  for me, it
> is easier to model a business problem as an object model rather than a
> relational model as u get easy inheritence, etc.  for us this translates
> to much more agile development/maintenance process.  of course u get
> back to the old trade-off of convenience/speed vs performance.
>

Here's where we have a design difference, I guess. I want the object model
to be at the BO layer, so they have the relationships, dependent objects,
etc. I'm all for using an object model, inheritance, etc. I just know that
it's so frequent that I have to send a row's data someplace, I want the data
in the DTO. Note that I like to use views to support inheritance in the
object model, though that fits best when you don't have a lot of extra
attributes in the various derived classes (otherwise the union of required
columns in the base table makes it a "wide" row w/ lots of nullable
columns).

FWIW...

Donnie

RE: [Hibernate-devel] SQL Server 2000 questions

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

For those who missed my earlier post:

> The one I have been using is JSQL from:
>
> http://www.j-netdirect.com/
>
> This particular driver seems to work beautifully.
>
> I have just verified that Weblogic jDriver also works (with one very
minor
> test failure).
>
> FreeTDS certainly does *not* work. I _think_ someone reported that
>
> http://www.inetsoftware.de/
>
> also does *not* work. (Havn't tried this myself)

> The latest version of Microsoft's driver doesn't pass all tests, but it
> does pass *some*. It might be almost possible to get it working, but I'm
> not particularly optimistic. (If you want to try, you _must_ use the
> SelectMethod=cursor JDBC connection parameter.)

Anton wrote:

> Not sure what the issues with MS driver are, but I've had good success
with
> the commercial driver JTurbo
> (http://www.newatlanta.com/products/jturbo/index.jsp).

I havn't tried this driver. Have you run the test suite against it?

The problem with the microsoft driver is not so much that hibernate's
support
for it is incomplete, so much as the fact that the driver itself does not
support some usage that _every_other_ jdbc driver I've tried _does_
support.

It wouldn't surprise me if you run into these problems even if you _don't_
use hibernate. In light of this, I would be more comfortable using JSQL or
Weblogic jDriver anyway (they cost money unfortunately).

RE: [Hibernate-devel] SQL Server 2000 questions

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

> I havn't tried this driver [JTurbo]. Have you run the test suite against
it?

I haven't run any of Hibernate's own tests with JTurbo yet, although I did
inherit from TestCase.java for my own tests.  I've been doing my own tests
with Hibernate, MS SQL, and JTurbo, on a set of about 100 persistent classes
that I've generated from an existing database.

So far, I haven't seen any problems, although I've mainly been doing
read-only stuff.  It hadn't even occurred to me that there might be
problems, since I've found JTurbo to be pretty solid.  I'll let you know
what happens when I get around to running Hibernate's tests.

> The problem with the microsoft driver is not so much that hibernate's
> support for it is incomplete, so much as the fact that the driver
> itself does not support some usage that _every_other_ jdbc driver
> I've tried _does_ support.

Why am I not surprised? ;)

Anton

RE: [Hibernate-devel] SQL Server 2000 questions

[Donnie H. <do...@ha...>]

Don't know if/when you'll get this, but thought I'd send it while I go off
and look  into things.

Are there instructions, or can you point me in the right direction, to run
the test suite against a particular JDBC driver / database? I want to run it
against SQL Server 2K w/ the MS JDBC driver just to see what I discover.

Many thanks,

Donnie Hale


> -----Original Message-----
> From: hib...@li...
> [mailto:hib...@li...]On Behalf Of
> Gavin_King/Cirrus%CI...@ci...
> Sent: Saturday, March 16, 2002 8:30 PM
> To: Donnie Hale
> Cc: hib...@li...
> Subject: Re: [Hibernate-devel] SQL Server 2000 questions
>
>
>
> The one I have been using is JSQL from:
>
> http://www.j-netdirect.com/
>
> This particular driver seems to work beautifully.
>
> I have just verified that Weblogic jDriver also works (with one very minor
> test failure).
>
> FreeTDS certainly does *not* work. I _think_ someone reported that
>
> http://www.inetsoftware.de/
>
> also does *not* work. (Havn't tried this myself)
>
> The latest version of Microsoft's driver doesn't pass all tests, but it
> does pass *some*. It might be almost possible to get it working, but I'm
> not particularly optimistic. (If you want to try, you _must_ use the
> SelectMethod=cursor JDBC connection parameter.)
>
> Good Luck
>
> Gavin
>
>
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>