Okay, here goes.
My company has a requirement that POJOs be customizable at runtime. We've put together a framework that allows POJOs to be created using a base implementation class that internally uses a HashMap to store additional properties that can be added at startup. (This allows for customization of our product in the field.) We provide our own property setters and getters to Hibernate to insure the base class's interface is used when necessary.
That's the easy part. The problem is, they now want for custom properties to be visible only in certain contexts. For instance, if a particular customer is selling products from multiple vendors, they may want to add property1 to instances of vendorA's products, and property2 to instances of vendorB's products. Different properties, different types, different rules. At first I suggested we simply add property1 and property2 to all instances and let the UI sort it out, but due to other constraints (real or perceived), they are pushing for a solution closer to the database.
My first thought was to dynamically create subclasses using CGLIB and register the subclasses using the "vendorID" as the discriminator. However, I'm having trouble wrapping my head around getting Hibernate to use the dynamically generated classes when necessary.
My second thought was to completely replace the EntityPersister to insert the appropriate columns when necessary. (The base class of our entities always guarantees storage for whatever properties we need, so the database side is the only part we need to worry about). However, the supplied EntityPersister implementations are not for the "faint of heart".
I am open to any and all suggestions.
Thanks,
Steve
|