Claus Radloff wrote:
Hi,
when we started, we had two distinct tables, but this solution was too slow, as we have a few hundred thousand texts. So we put our texts in one table. This improved the performance significantly.
Hmm, a decent database should be able to handle a foreign key relation between two tables well, even with miliions of records.
I would never compromise a clean database model in such a case!
Wouldn't be a mechanism to allow people to provide their own storage classes be of general interest? Or am I the only one with such unorthodox constructs?
You are the first requesting such a beast. I can imagine that there are very special cases where it makes sense to allow users to provide their own persistence mechanim. But as of today we did not see a general need.
But adding this would require some in depth analysis of the OJB codebase to find the best point of attack.
For the time being OJB offers other solutions:
you can define stored procedures in the database to load all required for your objects and in the repository_user.xml you can declare which stored procedure to use for which class.
Another solution thats already existing: You can implement your own SqlGenerator component. going this way you have full control over the sql generation.
Then on the next level you could also provide your own PersistenceBroker implementation...
With such a mechanism, one could also store/retrieve data from ldap or plain files etc.
SOunds interesting but it would require us to implement a two phase commit mechanism into the PersistenceBroker to cleanly handle the transactions against diffent target systems.
AT some point in time we decided to have a PersistenceBroker work agaisnt one and only one target system during one transaction.
So our approach is to implement dedicated PersistenceBrokers (one for LDAP, one for flat-file...)
cjeers, thomas
Regards
Claus
Am Mo, 2003-12-08 um 12.45 schrieb Antonio Gallardo:
Claus Radloff dijo:
Hi,
for some cases this could be a solution. But the majority needs the texts in all available languages, so the user can edit the description in these languages at once.
OK. I understand. For similars cases we builded a BeanList. And just search by the first value, living the language free.
A two tables can be your solution:
class TextType { Integer id; String type; String name; }
class Text { Integer id; Integer language; Map text; }
In the O/R mapping, in TextType define a collection for Text. This would work fine. We do the same for User and Permissions, where 1 user can have many permisions.
Is this OK? :-D
Best Regards,
Antonio Gallardo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
