where to put the node configuration information

[tom.baeyens]

for node configuration information, we said that we are going to put everything in the NodeBehaviour implementations and then wire those objects. That way we have a fixed db schema and extendable node implmentations.

I just want to discuss the tradeoffs of that approach here.

alternative a) We planned to put all the configuration information in NodeBehaviour. This implies that all the configuration information, such as bpel-sources, bpel-targets, and so on will have to be 'detyped' and stored in the form of wire descriptors in the db. That is of course a downside. On the positive side, this way we have a stable db schema.

alternative b) If we put the configuration information in the nodes, we still could map it with mixed inheritence. So that every process language has got its own extension table for node information.


this is what i was writing to charles in another topic on where to put the bpel sources and targets before i decided to move it here in a separate topic:

probably it's the best to put everything in the nodebehaviour. we can even create NodeDescriptors that use the already-existing long-column to store foreign keys to Nodes. That way, we're able to persist a list of nodes and store them in the wire schema.

But i'm not sure if this strategy is going to work out in the end when we actually do it.

I think we should go ahead with storing souces and targets (as lists of node-objects) in activity (which implements NodeBehaviour). We'll have to rewind if later it doesn't turn out to be a good decision to put everything in implementations of the NodeBehaviours and not directly extend the Node class.

[mvaldes]

I personally liked the approach started in the inheritance-mix prototype. PVM db schema remains the same (node + NodeBehaviour tables) while changes only impact the languages implementations:

BPEL_activity, JPDL_activity and XPDL_activity tables will contain the specific attributes (table columns) required by each node implementation: i.e links, partnerships, userid...

For sure this requires process languages updates when changing, adding or removing attributes from node implementations.

Are not those changes/updates easy to handle than working with wire descriptors persistence ?

Just to "fire" the debate :-)

regards,
Miguel Valdes

[tom.baeyens]

"mvaldes" wrote:
Are not those changes/updates easy to handle than working with wire descriptors persistence ?

that is definitely not the case. as messing with wire descriptors is a one time job that is done by us.

managing the db schema has to be done by our users, meaning the operators that keep our applications in production. so that effort needs to be multiplied by the number of installations of our products...

"mvaldes" wrote:
Just to "fire" the debate :-)

good that you did.

you reminded me of the previous outcome of this discussion. now, i recall that we were going to do the mixed inheritence for the process languages.

and if then the process languages need an extra configuration property, they still can use the wire descriptors to add that configuration property without touching the db schema.

so the mixed inheritence was used for the things we initially ship. and the wire descriptors are used for the additions/changes.

[mvaldes]

that is definitely not the case. as messing with wire descriptors is a one time job that is done by us.

managing the db schema has to be done by our users, meaning the operators that keep our applications in production. so that effort needs to be multiplied by the number of installations of our products...

I see your point but this is real life in mostly every software solution: when a new version is out a database migration tool must be provided...

but anyway, if we can do better, i'm ok with that !

you reminded me of the previous outcome of this discussion. now, i recall that we were going to do the mixed inheritence for the process languages.

and if then the process languages need an extra configuration property, they still can use the wire descriptors to add that configuration property without touching the db schema.
so the mixed inheritence was used for the things we initially ship. and the wire descriptors are used for the additions/changes.

Know I remember too (this is why a forum is useful :-) this is a good approach that I see we can easily apply for instance when adding a new node type. But what happen if we just need to add a new attribute in a previous Flow node implementation?
Shall we use wire descriptors for that ?

In this case it will not be always easy to know where things are stored...

regards,
Miguel Valdes

[tom.baeyens]

In this case it will not be always easy to know where things are stored...

that is indeed a drawback.

we can decide at the moment when we need to make the change. then we can still choose. suppose that e.g. this is the only DB change for a release, then we can have the option of going for the wire solution.

another approach might be that in micro releases, the db schema remains stable and we just use wire descriptors if we need to store more info in the db. Then, with the next minor release update, we can provide a DB migration tool that adds the new columns and cleans the wire descriptor stuff and translates it to the new columns...

[mvaldes]

I like the second option. Before first version (4.0) of our products (Milestones) I suggest to do not use wire descriptors. We can apply DB changes between two Milestones even without providing a database migration tool.

regards,
Miguel Valdes