Gavin King wrote:

Christoph, someone else once asked for this, so it might well be worth the
effort.

I hope it wasnt me :)

However, I wouldn't like to change the API if we can possibly help
it. Now, it might turn out that we don't need to change the API.

(1) How do you plan to persist these DynaBeans? A table that contains
property name/value pairs seems most reasonable if you need users to be able
to specify new properties at runtime ... or did you intend to export tables
dynamically at runtime?

I want to create a new table for each dynabean. Then I'd also implement the dynamic schema update that I was mentioning long time ago :)

(2) Would it be possible to load an instance like this:

session.load( DynaBean.class, new DynaBeanKey("dynamic.class.name",
identifier) );

cool, that would be a good way, since we wouldnt need to change the api.


(3) Not sure of the best way to write a ClassPersister for DynaBeans. Should there be a single persister for each class, or one for all classes? If the latter, you might need to change the ClassPersister interface to accommodate this new notion of a ClassPersister that persists multiple "classes". If the former, does that mean we need to be able to add new DynaBeanPersisters at runtime?

I think we should take the former option, one persister per class. Then we should be able to add new Persisters at runtime. (And change the field definitions of existing persisters)
hmm, do we need a new kind of class persister? I dont thimk so. IMHO the best solution would be to factor out the bean access of the existing ClassPersisters, and make that pluggable.




Gavin


----- Original Message -----
From: "Christoph Sturm" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 13, 2002 12:47 AM
Subject: [Hibernate] support for dynabeans




Hi All!

I'd like to implement a new feature in Hibernate, but I dont know how to
start best. I would like to be able to map classes that dont really
exist as javaclass, but use a dynabean instead



http://www.apache.org/~jvanzyl/jakarta-commons/beanutils/apidocs/org/apache/
commons/beanutils/DynaBean.html


(or a map). All seems to be quite easy, refactor all stuff that loads
and initializes a bean to a pluggable factory, and there if the loading
of the class fails just create or initialize a Dynabean or Map (or maybe
a HibernateGenericValueHolder) instead.

The only problem is:
The Hibernate API :)
Session.load, Session.update, etc all get a java.lang.Class Argument. Do
you think it would be possible to add functions that get a classname as
String instead?  Maybe the functions that take a string as argument
should always use Holders instead of beans.
I realize that this would be big changes, but if you think that this
would be a good idea, I would just go ahead and try to implement it.



The inspiration to this comes from the ofbiz entity engine, which always
uses generic holders instead of Beans, which i dont really like, but its
really nice for some usecases, e.g. letting your user add colums to a
table at runtime without restarting the server. I recognize that i could
dynamically generate a bean with bcel, but once that bean is loaded i
cant add properties to it, so I'd really prefer a map.

regards
chris




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel












------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel



Reply via email to