hibernate-devel — development

Re: FW: [Hibernate-devel] Is there a way to setup referential integrty?

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

> Nope, does not support the standard..
>
> instead it uses something like the following
>
> -- Referential integrity
> create table main(id int identity,name varchar)
> create table ref(id int identity,idMain int, foreign
key(idMain)references
> main(id))

Yeah I checked up on this last night. I can't see how we could use this
because hibernate allows tables to have circular foreign key references,
etc. whereas this would require that tables be created in a predefined
order. So I can't see how it would fit the model.

I think we'll have to leave it unsupported until HSQL implements an alter
table.

FW: [Hibernate-devel] Is there a way to setup referential integrt y?

[Marco P. <mar...@cm...>]

Nope, does not support the standard..

instead it uses something like the following

-- Referential integrity
create table main(id int identity,name varchar)
create table ref(id int identity,idMain int, foreign key(idMain)references
main(id)) 

So alter tables are not allowed, i did take a look at the Contraints class
but i see no way this would fit in...

Any suggestions on that ?
Could always try to check the people from Hsql when they will be supporting
alter table...

Greetings


-----Original Message-----
From: Gavin_King/Cirrus%CI...@ci...
[mailto:Gavin_King/Cirrus%CI...@ci...]
Sent: woensdag 17 april 2002 8:41
To: Marco Pas
Subject: RE: [Hibernate-devel] Is there a way to setup referential
integrty?




> i am using HSQLDB and i now that it supports constraints, i have set the
> dialect to HSQLDB but no constraints
> appear. I use a many-to-one mapping, are there any properties extra that
i
> have to set ?

yeah, it looks like HSQLDialect is written to not support foreign key
constraints. (I didn't write it myself.) Does HSQL use the standard
kind of SQL to create foreign key constraints? ie.

alter table add constraint....

If so, you probably just need to change HSQLDialect.hasAlterTable() and
possibly HSQLDialect.dropCOnstraints() to return true. Would you
have a play with that for me if you get a chance? TIA.


> In the understanding example i use a many-to-one mapping for clients /
> orders.
> A client can have multiple orders but and must refer to one client..
> So IMHO an order without a client should not be possible....
> After generating the DBSchemaExport and running the understanding
code.... i
> cam to the conclusion that it works perfectly.. That is not what i
expected!

Both the object and relational models support null references, so hibernate
does too! If you want to disallow a null reference, use the following
mapping:

  <class name="com.mticket.Client" table="Clients">
    <id name="clientId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="name"/>
  </class>

  <class name="com.mticket.Order" table="Orders">
    <id name="orderId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="description"/>
    <many-to-one name="client" column="clientId" not-null="true"
class="com.mticket.Client"/>
  </class>

[Hibernate-devel] Hibernate and debuglevel

[Marco P. <mar...@cm...>]

hibernate.debug=2

where do i put this...

I tried that to put it in a properties file, together with the rest of the
properties,
but i see no extra debug info....

-= This tagline is protected by international laws, (c) 1999 =-


Marco Pas

RE: [Hibernate-devel] Is there a way to setup referential integri ty?

[Marco P. <mar...@cm...>]

Gavin,

i am using HSQLDB and i now that it supports constraints, i have set the
dialect to HSQLDB but no constraints
appear. I use a many-to-one mapping, are there any properties extra that i
have to set ?

In the understanding example i use a many-to-one mapping for clients /
orders.
A client can have multiple orders but and must refer to one client.. 
So IMHO an order without a client should not be possible....
After generating the DBSchemaExport and running the understanding code.... i
cam to the conclusion that it works perfectly.. That is not what i expected
!

example
  <class name="com.mticket.Client" table="Clients">
    <id name="clientId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="name"/>
  </class>

  <class name="com.mticket.Order" table="Orders">
    <id name="orderId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="description"/>
    <many-to-one name="client" column="clientId"
class="com.mticket.Client"/>
  </class>

-- code snippet
SessionFactory sessions = ds.buildSessionFactory(props);
Session sess = sessions.openSession();

Order o = (Order) sess.create(com.mticket.Order.class);
o.setDescription( "Order description" );
sess.commit();
--



-----Original Message-----
From: Gavin_King/Cirrus%CI...@ci...
[mailto:Gavin_King/Cirrus%CI...@ci...]
Sent: woensdag 17 april 2002 7:15
To: Marco Pas
Cc: hib...@li...
Subject: Re: [Hibernate-devel] Is there a way to setup referential
integrity?



> Is it possible to use/enforce referential integrity within Hibernate,
using
> DBSchemaExport ?
> the DBSchemaExport creates perfect tables, but there is it possible to
let
> it also generate the referential integrity ?

certainly. foreign key constraints are generated for those databases which
support them. You need to set the system property hibernate.dialect when
running DBSchemaExport :)

RE: [Hibernate-devel] code generator

[Marco P. <mar...@cm...>]

Brad,

that would be very nice... in several ways...
As i am starting with Hibernate it is not always clear what kind of getters
/ setters i need to have to get
al the stuff working, so on a clean project.. where you can start with an
emty database and no code it would
be a real timesaver.. Also for learning / demo practices this could be very
helpfull..
I surely hope that the hibernate project will take this further..

Greetings

-----Original Message-----
From: Brad Clow [mailto:bra...@wo...]
Sent: woensdag 17 april 2002 1:53
To: hib...@li...
Subject: [Hibernate-devel] code generator



i have built a small code generator based on the hibernate mapping file.
it enables us to automatically generate the classes specified in the
mapping file (no hand writing all those getters and setters :-)).  i
have tried to make it extendable and configurable so that other classes
(eg. data access or business logic) or web pages, etc could also be
automatically generated.

so far, it has been a tool that has been built and added to as we have
needed, and therefore doesn't support all the mapping features
available.  for example it doesn't do:
	toplevel collections
	components
	primitive types

but it does do:
	nested collections
	one-to-many
	many-to-one

there is also no concept of regenerating changed existing classes and
automatically merging the changes.  finally, as this has not been a big
focus for us, the code/docs r not always very pretty.

in light of all that, i use it regulary and find it saves me time.  our
company (workingmouse.com) has decided that should there be any
interest, we can contribute it to the hibernate project.

in light of the recent discussions on automatic generation from a
database, i can't c y the code generator could not be extended to use
the mapping file, or an existing database.  currently, the code
generator processes the mapping file into it's own internal structure
(it can't use the existing hibernate code that does this as it relies on
reflection and the classes don't exist yet).  this initial processing
component could be made configurable and one that generates the internal
structure from an existing database be written.

brad

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

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

Re: [Hibernate-devel] Is there a way to setup referential integrity?

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

> Is it possible to use/enforce referential integrity within Hibernate,
using
> DBSchemaExport ?
> the DBSchemaExport creates perfect tables, but there is it possible to
let
> it also generate the referential integrity ?

certainly. foreign key constraints are generated for those databases which
support them. You need to set the system property hibernate.dialect when
running DBSchemaExport :)

[Hibernate-devel] Is there a way to setup referential integrity?

[Marco P. <mar...@cm...>]

Is it possible to use/enforce referential integrity within Hibernate, using
DBSchemaExport ?
the DBSchemaExport creates perfect tables, but there is it possible to let
it also 
generate the referential integrity ?


-= This tagline is protected by international laws, (c) 1999 =-


Marco Pas
CMG Trade Transport & Industry BV
Internet Software Engineering
Kralingseweg 241-249 3062 CE Rotterdam
Postbus 8566, 3009 AN Rotterdam
telefoon: +31 (0)10-2537000 / 7144
fax: +31 (0)10-2537301
e-mail: mailto:mar...@cm... <mailto:mar...@cm...> 

"The Information contained in this E-mail and its attachments is
confidential and may be legally privileged. It is intended solely for the
use of the individual or entity to whom it is addressed and others
authorised to receive it. If you are not the intended recipient you are
hereby notified that any disclosure, copying, distribution or taking any
actions in reliance of the contents of this E-mail and any attachments is
strictly prohibited and may be unlawful. CMG is neither liable for the
proper and complete transmission of the information contained in this E-mail
and any attachments nor for any delay in its receipt. If received in error,
please contact CMG on +31 (0)20 50 33 000 quoting the name of the sender and
the addressee and then delete it from your system. Please note that CMG does
not accept any responsibility for viruses and it is your responsibility to
scan the Email and attachments (if any). No contracts may be concluded on
behalf of CMG by means of E-mail communications."

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

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

> 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

[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

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

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] code generator

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

That sounds fantastic Brad. Assuming that other people like the idea as
much as I do, it would be a great contribution to the project.

[Hibernate-devel] input needed: exception messages

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

Hi everyone,

Now that quite a few people are using hibernate, I'd like to know how easy
people are finding debugging/troubleshooting in their systems. In
particular are there common mistakes that are hard to track down? Are there
any error messages that are misleading or give too little information?
Would a more complex exception class hierarchy be useful (ie. would anyone
find it useful to catch subclasses of HibernateException)?

Slightly related to this: would there be any advantage in having a "proper"
approach to logging events inside the persistence layer? (Beyond the
present rudimentary approach of System.out.println() when
hibernate.debug>0) We could pretty quickly rip out all the printlns and
replace them with log4j, for example. But perhaps people are wishing they
could see other kinds of information altogether.

Any other related ideas?

Thanks

Gavin

[Hibernate-devel] code generator

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

i have built a small code generator based on the hibernate mapping file.
it enables us to automatically generate the classes specified in the
mapping file (no hand writing all those getters and setters :-)).  i
have tried to make it extendable and configurable so that other classes
(eg. data access or business logic) or web pages, etc could also be
automatically generated.

so far, it has been a tool that has been built and added to as we have
needed, and therefore doesn't support all the mapping features
available.  for example it doesn't do:
	toplevel collections
	components
	primitive types

but it does do:
	nested collections
	one-to-many
	many-to-one

there is also no concept of regenerating changed existing classes and
automatically merging the changes.  finally, as this has not been a big
focus for us, the code/docs r not always very pretty.

in light of all that, i use it regulary and find it saves me time.  our
company (workingmouse.com) has decided that should there be any
interest, we can contribute it to the hibernate project.

in light of the recent discussions on automatic generation from a
database, i can't c y the code generator could not be extended to use
the mapping file, or an existing database.  currently, the code
generator processes the mapping file into it's own internal structure
(it can't use the existing hibernate code that does this as it relies on
reflection and the classes don't exist yet).  this initial processing
component could be made configurable and one that generates the internal
structure from an existing database be written.

brad

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

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] Please help with 1:n relationship

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

The column attribute in the following two lines should match:

<many-to-one name="Client" column="clientId" class="com.mticket.Client"/>

<key column="clientId"/>

The column attribute in the second line refers to the column of the
_referenced_ table, not the referencing table.

Have a close look at cirrus.hibernate.test.Master,
cirrus.hibernate.test.Detail and master_detail_map.xml for an example of
how to use bidirectional associations.

Re: [Hibernate-devel] Please help with 1:n relationship

[Marco P. <mp...@cm...>]

Gavin,

> the key column of the many-valued end must match the column of
> the single-valued end. Hope that makes sense.....
To summarize
- A client has multiple orders and an order has only one client --
- Client class has a clientId
- Order class a orderID

- At this moment i see a referral from the many-valued site (Order)
to the one site (Client)
	<many-to-one name="Client" column="clientId" class="com.mticket.Client"/>
but the referal from the single-value, is not yet clear..
	<set role="besteld" readonly="true">
		--> makes sense!
        	<key column="clientId"/>
		--> Is this the key column you mentioned ?
		Why does this refer to the clientId, looks like a self-referal!
         	<one-to-many class="com.mticket.Order"/>
		--> makes sense!
     	</set>

Do i need to have other property things in my classes to hold the
correct referals? Ath this moment i only have the getter ans setter
methods mentioned as properties in the mapping files..

Again a lot of questions ;-)

Greetings,
Marco



On Tue, 16 Apr 2002 Gavin_King/Cirrus%CI...@ci... wrote:

>
>
> Hi Marco. Try the following:
>
> <hibernate-mapping>
>   <class name="com.mticket.Client" table="Client">
>     <id name="clientId" type="long">
>       <generator class="cirrus.hibernate.id.HiLoGenerator"/>
>     </id>
>     <property name="name"/>
>
>     <set role="besteld" readonly="true">
>         <key column="clientId"/>
>         <one-to-many class="com.mticket.Order"/>
>     </set>
>   </class>
>
>   <class name="com.mticket.Order" table="order">
>     <id name="orderid" type="long">
>       <generator class="cirrus.hibernate.id.HiLoGenerator"/>
>     </id>
>     <property name="description"/>
>     <many-to-one name="Client" column="clientId" class
> ="com.mticket.Client"/>
>   </class>
> </hibernate-mapping>
>
>
> For a bidirectional association, one (many-valued) end must be marked
> read-only, telling hibernate to use the other end for updating persistent
> state. Also the key column of the many-valued end must match the column of
> the single-valued end. Hope that makes sense....
>
> peace
>
> Gavin
>

Re: [Hibernate-devel] Please help with 1:n relationship

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

Hi Marco. Try the following:

<hibernate-mapping>
  <class name="com.mticket.Client" table="Client">
    <id name="clientId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="name"/>

    <set role="besteld" readonly="true">
        <key column="clientId"/>
        <one-to-many class="com.mticket.Order"/>
    </set>
  </class>

  <class name="com.mticket.Order" table="order">
    <id name="orderid" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="description"/>
    <many-to-one name="Client" column="clientId" class
="com.mticket.Client"/>
  </class>
</hibernate-mapping>


For a bidirectional association, one (many-valued) end must be marked
read-only, telling hibernate to use the other end for updating persistent
state. Also the key column of the many-valued end must match the column of
the single-valued end. Hope that makes sense....

peace

Gavin

[Hibernate-devel] Please help with 1:n relationship

[Marco P. <mar...@cm...>]

I have problems understanding, the operations/settings nesecary for
the following example...

A client can place multiple orders, a order consists out of multiple
orderlines,
and an orderline contains a product.

I am starting with a simple example that a client just can place multiple
orders...
a order can only refer to 1 client so a one-to-many relationship....

I tried to use the following mapping..
-----------------------
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping SYSTEM "hibernate-mapping.dtd">
<hibernate-mapping>
  <class name="com.mticket.Client" table="Client">
    <id name="clientId" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>  
    <property name="name"/>
    
    <set role="besteld" table="order">
        <key column="Id" type="long"/>
        <one-to-many class="com.mticket.Order"/>
    </set>
  </class>

  <class name="com.mticket.Order" table="order">
    <id name="orderid" type="long">
      <generator class="cirrus.hibernate.id.HiLoGenerator"/>
    </id>
    <property name="description"/>
    <many-to-one name="Client" column="clientId"
class="com.mticket.Client"/>
  </class>   
</hibernate-mapping>
-----------------------
I am nut sure about the <many-to-one tags and the role....
Can someone help me out?

Greetings..
Marco

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

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

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