Hibernate version: 3.2.3.ga

Name and version of the database you are using: mysql5

Hello,

We have a system with a structure like this :

{customer}--has_one_to_many-->{account}--has_one_to_many-->{product}

This is pretty straight forward to map, excepted that the "product" entity is actually not a table in the database but a Java interface implemented by a complex object (this object calls different web services and other db systems).

So, is there a way to indicate to hibernate that the "products" attribute for "account" mapping is a custom defined CRUD DAO class ?

Hence, we would call "save" or "select" with the "customer" entity it would automatically call the appropriate CRUD methods on our custom objects?

Thank you very much for letting us know if this is possible or if we should look for another solution.

With Kind Regards,
Cédric B.

I am not getting the context well.But as per my understanding you want to make the product class read only(immutable).
If so you can make the class immutable by setting
class attribute mutable="false" in the mapping file of corresponding POJO

<class name="name" table="table" schema="schema" mutable="false">
</class>

A POJO is immutable if no public setter methods for any properties of the class are exposed.

If you want to
prevent saving of object properties set "insert" attribute of property to false
insert="false"
Hibernate wont consider these properties for insert statement

if this is not solving your problem you can write custom CUD operation
<class name....>
<id>
:
</id>
<sql-insert>
:
</sql-insert>
<sql-update>
:
</sql-update>
<sql-delete>
:
</sql-delete>
</class>

Hello Palodan,

Actually I do not think this is really what we want to do, although your tips will be helpfull anyway, so thanks a lot :)

I might attempt to reexplain because I poorly explained in the first post :

We would like to melt hibernate managed object with object not managed via hibernate.

Actually we have a DAO object implementation that can not be done with Hibernate, because it's not in database, but it is a set of web services calls.

So we are looking for a way to link it with hibernate framework because we would like to benefit from hibernate nice features such as the automatic managment (for example on save, update or select with lazy loading) of all one to many related entities.

For example if we take a simple libraries database. We have a library which contains shelves whose can contain books.

Easy to represent in a DB and map it with Hibernate in the cases all thoses entities are represented by DB tables, below is pseudo-code to save a library with all linked shelves and books :



If "Library", "Shelve" and "Book" are tables in the DB directly mapped in hibernate it will work easily.

If "Library" and "Shelve" are tables in the DB mapped in hibernate, but "Book" has no mapping in hibernate (because it can only be manipulated via a set of web services for example), then it won't work, hibernate will only be able to manage (save in the example) the library and the shelve, and we will have to manage all the "Book" manipulation manually at many different places in the project.

So I thought that we could implement a BookDAO that would not be implemented via classical hibernate calls, but via custom call to web services for example, and then link it in some ways with hibernate, so that the one to many links would be managed by hibernate framework. Even if at some points it has to use the custom BookDAO CRUD operations (performing web services call) instead of SQL requests.

I'm not quite sure if it is a lot clearer actually :\

Thank you very much in any cases, if you do have some hints it would be greatly appreciated :)

With Kind Regards,
Cédric B.

frankly saying I didnt get the context :)
I have some doubt in this context explanation

1.Do you have any table named Book in DB?
2.If you have any table named "Book" in DB whats the problem in doing a hibernate mapping?

3.What are the operations you require from Hibernate for this context?
eg.Save only,all CRUD operation , select operation only etc

Hello again Palodan,

1. Actually there are no table named "book" in the database, these data are managed by other means than db, although there are related to the existing DB.

3. Basically we would like to have save, delete, update and simple select operation managed automatically by Hibernate, in the case the table Book is managed by other persistant managment system (could be webservices, JDBC, ...)

Because I'm having hard time to explain it, I will try in a few lines, although after searching I think it is out of the scope of Hibernate :

I would like to use hibernate as a persistance managment framework (the standard usage for hibernate), but furthermore I would have liked to use it as a glue to link with any other persistant managment system.

In other words, actually hibernates can manage a table "A" having a relation with table "B" (where "B" is an existing table in the DB). This case works like a charm.

But it can not manage a table "A" having a relation with a DAO CRUD object "B" (where B is nowhere in the database, but just an interface providing basic CRUD operations).

I do not know either if such a framework, that could glue any persistant managment systems together as long as they use standardised CRUD methods exists.

Anyway, thank you very much for all your help ! :)

With Kind Regards,
Cédric

Hi Cedric,

I was at the same position years ago with Hibernate.

We had tables with one-to-many relationships to group->users. Alots of users had alots of documents, who get automatically indexed. The documents where not stored in the db, nor the keywords. They were stored in a Lucene (Java-Search-Engine) backend.

So if I wanted to get all docs by the user peter, you could write (pseudo) "select documentid from documents where user = 'peter'"

But "documents" is not a table by hibernate, documents is the lucene backend. If we added a new user to the system, the same user id was applied to all documents in the search index as "owner".

The reason for this was, that Lucene was manyfold superior to any in-database search functionality you can buy then (and even today).
And it was nice not to hit the already peaked db with stupid search requests ;)

But it was complex to access it in code. You can't work with sql, because hibernate doesn't liked mapping something that's not a db. We fixed this later by simply inserting a table and putting document ids into a "documents" table. But it was cumbersome, because sometimes the documentid didn't reflect the state under high load situations.

I don't know how this would be handled today (I speak about Hibernate 2.x) but I looked into the code and tried to "mimik" a table with a own dbdialect (which in case, would instead use a simple http interface to lucene and simulate rows and ids). But this seemed a heavy stretch and error prone.

Also, the Hibernate SessionFactory didn't allow multiple connection to different dbs then (I don't know how its today). So the real trick would be more like:

a) Create a HSQL string
b) Get the mapping
c) See that there is a "virtual" table mapped
d) Do the thing with the provided HSQL parameters on the "fake" db backend
e) Create a virtual table for hibernate to consumate
f) Execute the HSQL in hibernate
g) Enjoy the results ;)

I thought much about it back then, and I wonder that this is still a open(?), albeit quite esoteric request ;)

Maybe some of the main coders could shed some light on this problem?

greets
zenx