Re: Altering EOModel
Re: Altering EOModel
- Subject: Re: Altering EOModel
- From: "Elim PDT" <email@hidden>
- Date: Tue, 20 Jan 2009 13:40:37 -0700
Yes. if model changes can be made by data changes, we're done.
So we want to make eomodel somewhat more abstract and move model details
into (relational)database as data.
In that way, we want to make eo evolvable.
Every eo has its native class defined by eomodel. But we can assign a
runtime class/type to it by a typeID like this:
Create a table E_Type and entity/EOClass EType so that each EOClass
corresponding to an entry in table E_Type.
a parent-children reflexive relationship of EType is used to record the eo
class hierarchy.
a column propertyDict in table E_Type is used to store detailed/additional
class properties of an eoclass.
To alter an entity, we can modify the corresponding record in E_Type table;
to add new subclass at runtime, we add a record in E_Type under some node
(parent record). Objects with typeID corresponding to the id of the new
record will act like the "super class" by default but the behavior shall be
overrided by the propertyDict of the new type node.
Any tables we expect to have runtime schema changes will have a column
propertyDict where runtime-type-dependent-structured data will be stored
there.
Depends on your preferences, the content of propertyDict can be of
xml-formated or old golden aged propertyList (NSDictionary)
The idea was 5+ years old. Runs quite well for expert systems where the
knowledges/rules changes from time to time.
On Jan 19, 2009, at 2:33 PM, Stavros Panidis wrote:
is
my customer is a major department in a public hospital. Each time
they decide to perform an experiment and take in account different
measurements. No one can predict thi,s. So they need to have the
ability to create and/or alter existing tables.
Hi Stavros,
We do a lot of similar systems for healthcare and the situation you're
describing is fairly typical, especially when dealing with clinical
data. I agree with Suzanne though, implementing it by changing the
underlying tables is a recipe for trouble. Too many other pieces like
validation, reports, data feeds, data cubes, etc get really
complicated when the schema starts changing and the data gets ragged.
Typically we'd start to model this problem with a metadata structure
like a Procedure entity (the header record), an Aspect entity (things
that can be measured in a procedure, valid ranges, expected data
types), and a ProcedureAspect entity (the value of a given Aspect for
a Procedure).
Adding entries to the Aspect table is akin to changing the database
schema...it defines which attributes you expect for a Procedure...and
that's easily done at runtime.
-John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden