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