hibernate-devel — development

[Hibernate-devel] Re: JCS integration

[Christian M. <vc...@cl...>]

You rock ;)

There is something that could be considered as a future upgrade.
Atm each persistent class will have its own region cache, it might be
usefull to be able to put more than one persistent class in a region cache.

We could specify the following in the cache interface:

public void setClass(String  regionName) throws CacheException;

then if the user use the optional argument 'region' in the <jcs-cache>:

<jcs-cache usage="read-only" region="Test1"/>

then in the RootClass.java, if we find the region attribute, call :

jcs.setClass( regionName);

instead of

jcs.setClass( getPersistentClass() );


----- Original Message -----
From: <Gavin_King/Cirrus%CI...@ci...>
To: <hib...@li...>
Cc: <vc...@cl...>
Sent: Thursday, July 25, 2002 5:09 PM
Subject: JCS integration


> Christian Meunier got me started with some code to integrate Apache
> Tubine's JCS today. I ended up rewriting much of the Cache package and
> making some big improvements. Anyway, you may now specify a JCS cache in
> the mapping file using
>
>   <jcs-cache usage="read-only"/>
>
> or
>
>   <jcs-cache usage="read-write"/>
>
> You must then configure the cache in the resource /cache.ccf
>
> I will deprecate the old homegrown cache soon.
>
> JCS supports things like in-memory LRU caching, disk-caching, distributed
> caching, etc but be careful of using a distributed cache with usage
> ="read-write". That probably wont work.
>
> All in CVS....
>
>

[Hibernate-devel] Doc Addition

[Eric E. <ev...@pr...>]

A few suggestions for the docs:

First, here is some documentation on the --abstract switch for the mapping 
gen tool (modify as needed):
================================

--abstract=<i>full.class.Name</i>
The abstract switch directs the map generator tool to ignore specific super 
classes so that classes with common inheritance are not mapped to one large 
table.  For instance, consider these class hierarchies:

Animal-->Mammal-->Human
Animal-->Mammal-->Marsupial-->Kangaroo

If the abstract switch is <i>not</i> used, all classes will be mapped as 
subclasses of Animal, resulting in one large table containing all the 
properties of all the classes plus a discriminator column to indicate which 
subclass is actually stored.  If Mammal is marked as abstract, Human and 
Marsupial will be mapped to separate classes and stored in separate 
tables.  Kangaroo will still be a subclass of Marsupial unless Marsupial is 
also marked as abstract.

=================================

Second, I've noticed that when using JUnit, the 'reload classes for each 
test' option throws the logging system into a tail spin that prevents JUnit 
from running.  Using the JUnit "-noloading" application parameter prevents 
class reloading and avoids the problem - maybe this could be included in a 
FAQ section or something.

Third, I'm a IDE kind of guy (OK, I'm a lite-weight) and I never do 
*anything* using the command line.  The docs refer to running the tools 
from the command line - I find this to be a real pain because running these 
tools would require extremely long command line strings that are hard to 
get right, check, and keep track of.  What I did was to create a small 
class with some fill-in variables that creates my mapping and schema.  I 
can submit this if there is interest, but there is one hitch: The map gen 
tool creates a doctype declaration like this:

<!DOCTYPE hibernate-mapping SYSTEM "DTD_PATH/hibernate-mapping.dtd">

This is *always* unusable and it would be nice if it was modified to this:

<!DOCTYPE hibernate-mapping SYSTEM "hibernate-mapping.dtd"><!-- supply path 
to hibernate-mapping.dtd if needed -->

so that the generated mapping file is usable if the dtd is placed next to 
it.  This would allow my fancy automated map/schema tool to create the map 
and schema without having to remove the bogus path each time.

Cheers,

Eric Everman

[Hibernate-devel] JCS integration

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

Christian Meunier got me started with some code to integrate Apache
Tubine's JCS today. I ended up rewriting much of the Cache package and
making some big improvements. Anyway, you may now specify a JCS cache in
the mapping file using

  <jcs-cache usage="read-only"/>

or

  <jcs-cache usage="read-write"/>

You must then configure the cache in the resource /cache.ccf

I will deprecate the old homegrown cache soon.

JCS supports things like in-memory LRU caching, disk-caching, distributed
caching, etc but be careful of using a distributed cache with usage
="read-write". That probably wont work.

All in CVS....

Re: [Hibernate-devel] Documentation in DocBook

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

>> 3. I think the persistent-classes and basic-or-mapping sections should
come
>> before the session-configuration section. Otherwise the order seems
good.

>Hm. My first approach would be to read the "how to get it up and
>running; aka configuration" and after that I will look into how to do
>basic things. That was my approach when getting in contact with
>hibernate and I jumped alot around the documentation to get a basic
>"configuration, load, manipulate, store"-cycle going. I think it's
>better that way (further down my todo-list is a rewrite and cleanup of the
>configuration section).

Okay, I hadn't realized that you were planning a quickstart guide. That
changes things.... But could we temporarily move those sections earlier,
then move them back to where they are now when the quickstart guide is
complete? I just liked having the stuff about persistent classes right
slap bang upfront so everyone sees how they don't have to do anything
special.

more in a sec....

Re: [Hibernate-devel] Documentation in DocBook

[Christian B. <chr...@bl...>]

On 25 Jul (14:43), Gavin_King/Cirrus%CI...@ci... wrote:

> 1. currently, all <title> elements are transformed to <h2>. It would be
> much nicer if sect1/title would by rendered as <h3>.

I'll fix that.

> 2. can we get rid of the <p> tags inside <li> in the HTML version? (A minor
> issue, I suppose)

Yes, but only in the stylesheets. The docbook requires a para in a
listitem in XML.

> 3. I think the persistent-classes and basic-or-mapping sections should come
> before the session-configuration section. Otherwise the order seems good.

Hm. My first approach would be to read the "how to get it up and
running; aka configuration" and after that I will look into how to do
basic things. That was my approach when getting in contact with
hibernate and I jumped alot around the documentation to get a basic
"configuration, load, manipulate, store"-cycle going. I think it's
better that way (further down my todo-list is a rewrite and cleanup of the
configuration section).

Of course, if you insist, just move it around.

> I have a long todo-list now so it may take me a couple of days to get round
> to everything.

Me too, I won't have any time until next week, so your changes will be
checked in first.

-- 
Christian Bauer
tu...@in...

Re: [Hibernate-devel] Documentation in DocBook

[Christian B. <chr...@bl...>]

On 24 Jul (22:41), Anton van Straaten wrote:

> I haven't been following this too closely, other than to notice how amazing
> it all is - I love the pdf.  But it had occurred to me previously that it
> might be worth having more than one index into the docs, at least for the
> HTML version.  A "reference" index and a "tutorial" index, basically.  Also,
> I would imagine that over time, stuff would end up in the reference section
> that wouldn't necessarily be appropriate in the tutorial.

Ok, I think I should point out the plan I have in my head for the
"Documentation" section of hibernate:

* QUICKSTART
 - different beginners level documents (in form of articles)
 - special case documents ("Quickstart: Integration with JBoss 3.0")

* REFERENCE
 - complete reference documentation for alle functions and tools (book)

* TUTORIALS
 - from beginner to expert and different scenarios (articles)

-- 
Christian Bauer
tu...@in...

Re: [Hibernate-devel] Documentation in DocBook

[Christian B. <chr...@bl...>]

On 25 Jul (11:53), Gavin_King/Cirrus%CI...@ci... wrote:

> I need more time to think some of the reordering through .... the
> previous order was designed to get people started as quick as
> possible ... topics went from "basic" to "advanced". The new
> ordering is much more by subject which makes it more readable
> for most users but perhaps harder for brand new users just
> getting started. Anyway, I will put some thought into this and
> perhaps suggest some further changes.

My initial intention was to provide a complete reference documentation
for all features. One of the next steps would be to provide "Quickstart"
documentation for different scenarios. But I don't think this should be
_in_ the reference documentation.

> cool. unfortunately I'm having trouble checking this stuff out of CVS.
> Are you sure you checked in all the binary files with -kb?

Gah, used -ko, my fault. I think this can be fixed with a cvs admin -kb
command?

> I would very much prefer Ant if its at all possible. I've finally
> started using the ant build script to generate javadoc, etc, So
> it would be really nice to integrate this stuff with the existing
> stuff. My dream is to eventually be able to do a whole release
> with just a single Ant task but I'm not there yet ;)

OK, I will try Ant.

> yes, I would like to do this stuff for 1.0.2 if possible, since I want
> to document the new 1.0.2 features in docbook. Could you tell me
> exactly how up to date the docbook text is compared to the aft text? I
> did make a couple of minor changes this week and I might need to copy
> them over.

You will need to add your changes, the converted version is more than a
week old.

P.S. I'm subscribed to the devloper list, no need to Cc. :)

-- 
Christian Bauer
tu...@in...

AW: [Hibernate-devel] Documentation in DocBook

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

Hey all!

> -----Urspr=FCngliche Nachricht-----
> Von: hib...@li...=20
> [mailto:hib...@li...] Im=20
> Auftrag von Gavin_King/Cirrus%CI...@ci...
> Gesendet: Donnerstag, 25. Juli 2002 03:54
> An: Christian Bauer
> Cc: hib...@li...
> Betreff: Re: [Hibernate-devel] Documentation in DocBook

> >>- Write makefiles and documentation for automatic output generation
>=20
> >Still pending because I haven't decided for make or Ant.
>=20
> I would very much prefer Ant if its at all possible. I've=20
> finally started using the ant build script to generate=20
> javadoc, etc, So it would be really nice to integrate this=20
> stuff with the existing stuff. My dream is to eventually be=20
> able to do a whole release with just a single Ant task but=20
> I'm not there yet ;)
+1 for ant :)=20
Are there some problems doing it with ant, or why did you think about
using make?
I didnt use make for about 3 years now, and I'm really happy with it :)
>=20
> >>- Checkin to CVS
>=20
> >Done, with a lot of cursing about CVS over ssh. I cannot use any=20
> >graphical client with Unix... any solution for this problem?
>=20
> In my experience the graphical clients are really not worth
> the effort. I just use the cmd-line client under win2k, even=20
> though I _could_ use winCVS.

If you are using windows, you should definately check out tortoise cvs,
its an awesome cvs client :)
http://tortoisecvs.sourceforge.net/

Cheers
 Chris

Re: [Hibernate-devel] Documentation in DocBook

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

Okay, I had a better chance to play with everything

If anyone else wants to check out the new doco, be sure to use

   cvs upd -kb

since images are checked in as text. We will have to fix that.

Changes I'd like to see (some may not be possible):

1. currently, all <title> elements are transformed to <h2>. It would be
much nicer if sect1/title would by rendered as <h3>.

2. can we get rid of the <p> tags inside <li> in the HTML version? (A minor
issue, I suppose)

3. I think the persistent-classes and basic-or-mapping sections should come
before the session-configuration section. Otherwise the order seems good.

4. The full_cream and lite architecture diagrams don't quite represent the
same relationships I was trying to convey in the old diagrams. I will fix
this. (The other architecture diagram is an improvement upon what I had.)

5. There is a bunch of important stuff presented as lists which really
should be presented using tables now. The reason for the lists was that AFT
didn't give me a good way to create tables. I will fix this ASAP.

I have a long todo-list now so it may take me a couple of days to get round
to everything.

:)

RE: [Hibernate-devel] Documentation in DocBook

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

> I need more time to think some of the reordering through .... the
> previous order was designed to get people started as quick as
> possible ... topics went from "basic" to "advanced". The new
> ordering is much more by subject which makes it more readable
> for most users but perhaps harder for brand new users just
> getting started.

I haven't been following this too closely, other than to notice how amazing
it all is - I love the pdf.  But it had occurred to me previously that it
might be worth having more than one index into the docs, at least for the
HTML version.  A "reference" index and a "tutorial" index, basically.  Also,
I would imagine that over time, stuff would end up in the reference section
that wouldn't necessarily be appropriate in the tutorial.

Anton

Re: [Hibernate-devel] Documentation in DocBook

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

>>- Move chapters and sections around for a more consistent read

>Done. I hope this is an improvement.

I need more time to think some of the reordering through .... the
previous order was designed to get people started as quick as
possible ... topics went from "basic" to "advanced". The new
ordering is much more by subject which makes it more readable
for most users but perhaps harder for brand new users just
getting started. Anyway, I will put some thought into this and
perhaps suggest some further changes.

>I still have some ideas left and
>like to rewrite some chapters (especially the transaction and
>association handling, which seems most confusing for hibernate
>beginners, including myself).

Yeah, spot on.

collections:
Many users seem to have trouble the first time they map an
association. But only ever that first time. That definately
points to problems in the doco.

transactions:
Just recently I've noticed lots of people with problems arising
from forgetting to flush the session when not using the
Transaction API. Also people are uncomfortable calling
Transaction.commit(), Transaction.rollback() when using
container managed transactions. It needs to be clearer that
this doesn't actually call UserTransaction.commit(),
UserTransaction.rollback().

>>- Convert graphics to vector and make a small styleguide for this

>Done. We are using OpenOffice Draw, because it's the only cross
>platform vector drawing tool. Try it, it's not that bad if you know
>how to use it.

cool. unfortunately I'm having trouble checking this stuff out of CVS.
Are you sure you checked in all the binary files with -kb?

>>- Prepare stylesheets for HTML version

>Modified stylesheets. Sorry, I didn't use the hibernate css (blue
>background), because the images are not transparent and I don't have
>time to fix this. It doesn't lock that bad either and could be easily
>changed later.

Its beautiful. The only problem with presentation at the moment is I
think subsection headings are too large. I might be able to fix this
just by fiddling the css. I'll have a look later.

>>- Write makefiles and documentation for automatic output generation

>Still pending because I haven't decided for make or Ant.

I would very much prefer Ant if its at all possible. I've finally
started using the ant build script to generate javadoc, etc, So
it would be really nice to integrate this stuff with the existing
stuff. My dream is to eventually be able to do a whole release
with just a single Ant task but I'm not there yet ;)

>>- Checkin to CVS

>Done, with a lot of cursing about CVS over ssh. I cannot use any
>graphical client with Unix... any solution for this problem?

In my experience the graphical clients are really not worth
the effort. I just use the cmd-line client under win2k, even
though I _could_ use winCVS.

>So, if everyone agrees that the new documentation can replace the old
>"Programming Guide", the following steps would be neccessary:

yes, I would like to do this stuff for 1.0.2 if possible, since I want
to document the new 1.0.2 features in docbook. Could you tell me
exactly how up to date the docbook text is compared to the aft text? I
did make a couple of minor changes this week and I might need to copy
them over.

>Thats it. Hm, the "Toolset Guide" could be integrated as a separate
>chapter?

yep. And we should probably move the documentation of Dialects
somewhere else, since they are no longer used only by the schema
generator, as was originally the case.

>The website itself could do with little reorg, too. I think the
>whole Q&A and feature list is really one big block itself.

The website could do with many improvements actually.....

Thanks for all this Christian, its awesome.

Re: [Hibernate-devel] Documentation in DocBook

[Christian B. <chr...@bl...>]

On 20 Jul (03:26), Gavin_King/Cirrus%CI...@ci... wrote:

> >- Move chapters and sections around for a more consistent read

Done. I hope this is an improvement. I still have some ideas left and
like to rewrite some chapters (especially the transaction and
association handling, which seems most confusing for hibernate
beginners, including myself).

> >- Convert graphics to vector and make a small styleguide for this

Done. We are using OpenOffice Draw, because it's the only cross platform
vector drawing tool. Try it, it's not that bad if you know how to use
it.

> >- Improve DSSSL stylesheet for PDF generation

Well, I did the best I could. Some things are still not nice (the
Revision history) but difficult to fix. I think we should stay with the
current layout until next time...

> >- Prepare stylesheets for HTML version

Modified stylesheets. Sorry, I didn't use the hibernate css (blue
background), because the images are not transparent and I don't have
time to fix this. It doesn't lock that bad either and could be easily
changed later.

> >- Add "Best Practices" chapter

Done.

> >- Write makefiles and documentation for automatic output generation

Still pending because I haven't decided for make or Ant. This stuff is
really complex and involves about 10 different shell commands for a
complete conversion with about 8 different tools. My current helper
scripts and all stylesheets (PDF and HTML) are _not_ in CVS. The
stylesheets require some serious cleanup before everything is in the
right place and ready for the repository.

> >- Checkin to CVS

Done, with a lot of cursing about CVS over ssh. I cannot use any
graphical client with Unix... any solution for this problem?

So, if everyone agrees that the new documentation can replace the old
"Programming Guide", the following steps would be neccessary:

- Change the link on the left frame from "Programming Guide" to
  "Documentation"

- Link it to doc/reference/index.html in the right frame

Thats it. Hm, the "Toolset Guide" could be integrated as a separate
chapter? The website itself could do with little reorg, too. I think the
whole Q&A and feature list is really one big block itself. 

-- 
Christian Bauer
tu...@in...

RE: [Hibernate-devel] JBoss MBean

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

I have checked in a first-cut of the Hibernate MBean. It's loosely based
on John's original code with most of the changes we discussed on the
list. This is completely untested but since I havn't got JBoss installed
just yet, if someone else wants to try it out and track down issues,
they are very welcome ;)

The cirrus.hibernate.jmx package contains the offending classes.

[Hibernate-devel] New functionality

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

Just went through the smaller things on my todo list and checked in the
following (among other changes)

 * support for subqueries
 * JDBC batch execution of collection inserts (if a property is set)
 * suppress setAccessible() for public members (for locked-down servers)
 * another performance enhancement for collections

So you can now write queries like:

  from foo in class Foo where foo.count > ( select avg(bar.count) from bar
in class Foo )
  from foo in class Foo where foo.bar = some ( select bar from bar in class
Bar where bar.name=? )

okay, the second query is much more easily expressed w/o the subquery
but this is an example.....

Gavin.

Re: [Hibernate-devel] MySQL dialect / schema generator

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

I just checked some changes to the MySQLDialect into CVS. This addresses
problems storing large images or text. (Not exactly what Warwick suggested
but he pointed the way...)

Re: [Hibernate-devel] Documentation in DocBook

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

>OK, I managed to get the basic conversion done right now. Have a look at
>the PDF version and a quick zip of the XML source files:
>
>http://incubus.de/~turin/hibernate_reference.pdf
>http://incubus.de/~turin/hibernate_reference_dbxml.tar.gz

Awesome! The PDF looks great. I'm so excited ;)

>- Move chapters and sections around for a more consistent read
>- Convert graphics to vector and make a small styleguide for this
>- Improve DSSSL stylesheet for PDF generation
>- Prepare stylesheets for HTML version
>- Add "Best Practices" chapter
>- Write makefiles and documentation for automatic output generation
>- Checkin to CVS

All good. I have the original diagrams as visio documents (lame, i
know) and I can send those if it would help at all.

>This will take some days, maybe I can checkin a version early next week.
>It's all not too difficult but time consuming stuff...

I know how time consuming it is - your work is very appreciated :)

Thanks

Gavin.

Re: [Hibernate-devel] best practices doc (1 class, 1 mapping xml)

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

>is there any technical advantage to this, or just the easthetic
>pleasure? :)

To me this is most important when developing in a team. Managing a
monolithic mapping file is very difficult if everyone is trying to
edit it at once. (But yeah, I do also find it improves the
aesthetics.)

>i was thinking i could help out w/ writing an xDoclet generator for the
>mapping file, so you can put the mapping directly in you class.... would
>that make sense?

Absolutely it would make sense :) Someone suggested this a few versions
ago but nothing ever came of it. I don't know much about xDoclet myself.

Gavin

[Hibernate-devel] Documentation in DocBook

[Christian B. <chr...@bl...>]

On 19 Jul (18:30), Gavin_King/Cirrus%CI...@ci... wrote:

> Absolutely. If you can check in some example docbook stuff for me
> to work from, I will make this my chance to learn docbook....
> 
> Looking forward to seeing the new doco Christian :)

OK, I managed to get the basic conversion done right now. Have a look at
the PDF version and a quick zip of the XML source files:

http://incubus.de/~turin/hibernate_reference.pdf
http://incubus.de/~turin/hibernate_reference_dbxml.tar.gz

To-Do:

- Move chapters and sections around for a more consistent read
- Convert graphics to vector and make a small styleguide for this
- Improve DSSSL stylesheet for PDF generation
- Prepare stylesheets for HTML version
- Add "Best Practices" chapter
- Write makefiles and documentation for automatic output generation
- Checkin to CVS

This will take some days, maybe I can checkin a version early next week.
It's all not too difficult but time consuming stuff...

-- 
Christian Bauer
tu...@in...

Re: [Hibernate-devel] best practices doc (1 class, 1 mapping xml)

[Viktor S. <phr...@im...>]

hi,

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

>***place each class mapping in its own file
>Don't use a single monolithic mapping document. Map |com.eg.Foo| in the
>file |com/eg/Foo.hbm.xml|.
>
>  
>

is there any technical advantage to this, or just the easthetic 
pleasure? :) w/ the automatic xml mapping reloading (i think it came up 
related to the MBean) it would actually make that less efficient.

i was thinking i could help out w/ writing an xDoclet generator for the 
mapping file, so you can put the mapping directly in you class.... would 
that make sense?

    viktor

Re: [Hibernate-devel] best practices doc

[Christian B. <chr...@bl...>]

On 19 Jul (11:25), Gavin_King/Cirrus%CI...@ci... wrote:

> I'd like to throw this up for discussion. Anybody disagree with any of
> these points or have any new ones?
> 
> ==================================================================
> 
> *Hibernate ''Best'' Practices

I agree with all of this practices and it is of course essential for a
beginner to know about this things.

I hope I will finish the DocBook transition today, how about an 
additional chapter "Best Practices"?  

-- 
Christian Bauer
tu...@in...

[Hibernate-devel] best practices doc

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

I'd like to throw this up for discussion. Anybody disagree with any of
these points or have any new ones?

==================================================================

*Hibernate ''Best'' Practices

***use fine grained objects
Write fine-grained classes and map them using |<component>| or
|<component-element>|. Use an |Address| class to encapsulate |street|,
|suburb|, |state|, |postcode|. This encourages code reuse and simplifies
refactoring.

***declare identifier properties on persistent classes
Hibernate makes identifier properties optional. There are all sorts of
reasons why you should use them. We recommend that identifiers be
'synthetic' (generated, with no business meaning) and of a non-primitive
type. For maximum flexibility, use |java.lang.Long| or |java.lang.String|.

***place each class mapping in its own file
Don't use a single monolithic mapping document. Map |com.eg.Foo| in the
file |com/eg/Foo.hbm.xml|.

***load mappings as resources
Deploy the mappings along with the classes they map.

***consider externalising query strings
This is a good practice if your queries call non-ANSI-standard SQL
functions. Externalising the query strings will make the application more
portable.

***use bind variables
As in JDBC, _always_ replace non-constant values by "?". Never use string
manipulation to bind a non-constant value in a query!

***don''t manage your own JDBC connections
Hibernate lets the application manage JDBC connections. This approach
should be considered a last-resort. If you can't use the built-in
connections providers, consider providing your own implementation of
|cirrus.hibernate.connection.ConnectionProvider|.

***consider using a custom type
Suppose you have a Java type, say from some library, that needs to be
persisted but doesn't provide the accessors needed to map it as a
component. You should consider implementing |cirrus.hibernate.UserType|.
This approach frees the application code from implementing transformations
to/from a Hibernate type.

***use hand-coded JDBC in bottlenecks
In performance-critical areas of the system, some kinds of operations (eg.
mass update/delete) might benefit from direct JDBC. But please, wait until
you _know_ something is a bottleneck. And don''t assume that direct JDBC is
_necessarily_ faster.

If need to use direct JDBC, it might be worth opening a Hibernate |Session|
and using that SQL connection. That way you can still use the same
transaction strategy and underlying connection provider.

***in a three tiered architecture, consider using |update()|
When using a servlet / session bean architecture, you could pass persistent
objects loaded in the session bean to and from the servlet / JSP layer. Use
a new session to service each request. Use |Session.update()| to update the
persistent state of an object.

***in a two tiered architecture, consider using session disconnection
When using a servlet only, you may reuse the same session for multiple
client requests. Just remember to disconnect the session before returning
control to the client.

RE: [Hibernate-devel] Multi Table Support

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

>What about the option of defining a custom map object for a class.  For
>those special cases  (such as multiple table mappings), the custom map
>could handle the mapping to the database using hand coded SQL.

I've wondered about that in the past, but I can't imagine how we could
possibly integrate such objects with the query language.

I don't want to implement something like this at this stage just because
of the cost to the complexity of the already-too-complex core persistence
engine (ie. RelationalDatabaseSession.java). Right now this doesn't pass
my bloat-filter.

Now, a challenge to everyone here:

  How can we componentize RelationalDatabaseSession?

I would *love* to refactor this class into a few different classes but I
can't see how to do this without making the code actually *less* rather
than *more* readable. If there are any hardcore OO modellers here, lets
see what you can come up with!

There is one refactoring planned already (for 1.0.3) - namely factoring
all the find/iterate/etc code out to a seperate class the implements
a new paginating cirrus.hibernate.Query interface. This will actually
do a lot to help the situation, i think. But other suggestions are *very*
welcome!

Re: [Hibernate-devel] Multitable Persitency

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

>I started to mess around with the source. I allready made the Schema
>Genarator work with my first test.

cool. which means you came into contact with the cirrus.hibernate.map
package, presumably? That code is an abomination (partly because it
currently tolerates all versions of the mapping dtd back to 0.9.1).

>- how about this version column? its just something that can be declared
>in one of the superclasses and should be inherited to the subclass - am
>i correct?

Yes, exactly. Theres going to be some subtleties related to this .....
lets worry about them later, though.

>Doing Inserts:
>I will have to do multiple Inserts. So if a polymorphic Class has it own
>table i will first call the parent classes insert Statement and then
>the classes own statement.

yeah cool. Is the best way to have two ClassPersister subclasses or to
have a whole bunch of ugly if/elses in ClassPersister? Presently
ClassPersister is a final class with very many final fields....

>The only question that arises is native key
>generation. I will try not to use native generation uneless this is the
>root table of the polymorphic chain and then use this key in the other
>inserts that follow.

Cool. Hadn't occurred to me.

> The source look quite nice and is mostly very readable. I hope I can
> keep the Standard.

Please flag confusing areas to me, so we can improve them. (And if
you spend a few minutes looking at something and then figure it out,
please add a comment.) Everything was built very XP-style from the
start, ie. there was no upfront design or formal requirments, only
the automated tests.

peace

RE: [Hibernate-devel] JBoss MBean

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

> >>public void setProperties(String properties);<<
>
>Would this be properties that are normally placed in the
>hibernate.properties file?

yes, exactly. this would let you list the properties as
a comma-seperated list in the jcml file, and change them
dynamically from a management client.

Some of the properties are so important they warrant their
own attribute on the MBean, but not *all* of them...

[Hibernate-devel] Multitable Persitency

[Roman S. <hib...@gr...>]

Hi!

I started to mess around with the source. I allready made the Schema 
Genarator work with my first test.

At the moment the following questions came to my mind:

- how about this version column? its just something that can be declared 
in one of the superclasses and should be inherited to the subclass - am 
i correct?

Doing Inserts:
I will have to do multiple Inserts. So if a polymorphic Class has it own 
table i will first call the parent classes insert Statement and then 
the classes own statement. The only question that arises is native key 
generation. I will try not to use native generation uneless this is the 
root table of the polymorphic chain and then use this key in the other 
inserts that follow.

The source look quite nice and is mostly very readable. I hope I can 
keep the Standard.

cheers
roman