
we need to implement stuff to allow users to merge models!! * do we need to allow people to change the tag (CDS, CDS_after,...) of a model? that would allow them to 'merge' models (because you can only merge models with the same kind of tag, and you need to be able to tag is as 'CDS' to be processed) * merged models will be inserted without a problem. but then the problem starts... ** then we need to make the overlapping models obsolete. (maybe use the locked table for this??) ** the query for the 'context' (and so) will need to be changed to deal with these obsolete models. L.

Lieven Sterck schreef:
we need to implement stuff to allow users to merge models!!
* do we need to allow people to change the tag (CDS, CDS_after,...) of a model? that would allow them to 'merge' models (because you can only merge models with the same kind of tag, and you need to be able to tag is as 'CDS' to be processed)
Should be no problem. I can start working on this on monday.
* merged models will be inserted without a problem. but then the problem starts... ** then we need to make the overlapping models obsolete. (maybe use the locked table for this??)
** the query for the 'context' (and so) will need to be changed to deal with these obsolete models.
Delete the obsolete models. However, I don't think it is such a good idea to actually delete stuff. I see two possible solutions. First on, add an extra field to the table that contains the models to indicate whether this model is deleted. That field can be updated if something is merged, removed, ... All queries should be updated to take this new field into account. Another solution is to add a new table with exactly the same layout as the current models table and move the data from the current table to the new one when something is removed. That way no queries need to be rewritten as the current table only contains actual models, while still no data can be lost because it is copied to the new table before deletion. I don't think any of the queries outside the update script should be updated, but that depends on the current design. I would go with the second solution. T
participants (2)
-
Lieven Sterck
-
Thomas Abeel