Hibernate Question...

[nobody]

My company is going to bite the bullet and rewrite it's java persistence
layer. Our problem is that we dynamically create tables and the classes
to access them. So, a user might trigger the server to create a new set
of tables and will then populate and query them.

Is hibernate capable of handling that sort of dynamism? Is there
anything stopping me from dynamically creating whatever Hibernate needs
to do its magic?

If anyone can point me toward some useful text on this subject I'd be
grateful.

alan

 

[Gerbrand]

nobody schreef:

My company is going to bite the bullet and rewrite it's java persistence
layer. Our problem is that we dynamically create tables and the classes
to access them. So, a user might trigger the server to create a new set
of tables and will then populate and query them.

Is hibernate capable of handling that sort of dynamism? Is there
anything stopping me from dynamically creating whatever Hibernate needs
to do its magic?

If anyone can point me toward some useful text on this subject I'd be
grateful.

I would think it would be better to alter your design. In stead of
creating query's you can better just create data. There's nothing more
or less you can do that way.
Tables should only be created once when the application is installed or
developed.
You don't have any problems with how to create tables.

 

[nobody]

Unfortunately that won't work for this applicaiton. It used to be that
way, but that involved stopping, upgrading and restarting the server
whenever a new tool was added. We can't put the information in generic
tables unless we stored everthing as strings.

So...

Is there an adequate ORM tool that we can plug into our current design.
And, given our peculiar constraints, would an orm tool really buy us
very much, as we're having to defined the O/R mapping dynamically also.

alan

 

[Oscar kind]

My company is going to bite the bullet and rewrite it's java persistence
layer. Our problem is that we dynamically create tables and the classes
to access them. So, a user might trigger the server to create a new set
of tables and will then populate and query them.

Ouch: this means that during development, you don't know what problems you
can expect during production: the new classes have not been tested.

If however, the created classes follow a specific pattern, it's best to
model that pattern in separate database tables. This way the classes are
static, and guaranteed to be tested when in production.

Is hibernate capable of handling that sort of dynamism? Is there
anything stopping me from dynamically creating whatever Hibernate needs
to do its magic?

Yes. If you can create classes, you can use the same method to access the
Hibernate configuration. The tools from Hibernate can also be called from
your code to update the database dynamically. Beware though, that not all
table changes are supported.

If anyone can point me toward some useful text on this subject I'd be
grateful.

Documentation can be found on the Hibernate website:
http://www.hibernate.org/5.html

Of interest is the reference manual:
http://www.hibernate.org/hib_docs/reference/en/html/

The reference manual contains information to:
- Programmatically configuring Hibernate (section 3.1)
- Calling the SchemaUpdate tool (section 15.1.5)

 

[nobody]

Ouch: this means that during development, you don't know what problems you
can expect during production: the new classes have not been tested.

If however, the created classes follow a specific pattern, it's best to
model that pattern in separate database tables. This way the classes are
static, and guaranteed to be tested when in production.

The classes follow a pattern (otherwise it would be tough to generate
them). The problem is that the fields within the dynamic class are all
typed. Some longs, some Strings, some Dates etc,

If we were to maintain type safety in the db tables, we'd have to invert
our database structure (or 'pivot' it about the type value), so we'd
have a table for each type. All the 'long's from every dynamically
generated class would be in one table, all the Dates in another, etc...

This method would then screw up any users who might dream of accessing
their data with ad hoc queries, although views could be used to aid in
that. However, joining on all those different tables for every query
will also have performance ramifications. An object consisting of
fields of 4 different types (3 long fields, 4 Date fields, 2 String
fields and a clob) would be joining on 4 different tables just to
retrieve a single record.

That isn't to say that I don't think the idea of static tables isn't
something that we'd benefit from. Just that there are serious obstacles
in getting from here to there.

Thanks for the info...

alan