[jboss-as7-dev] problems with deployment overlays and linking

I've been prototyping a CLI command that manages deployment overlays and got worried :) I think, the current representation (actually, the data structure, in other words) of the overlays and their linking in the management model will lead to a lot of issues related to consistency of the data and complicate management of deployments in general. Basically, it's a many-to-many relationship between overlays and deployments. Currently, overlays and deployments are defined separately and linked using the "third table", each row of which consists of a link name, overlay name and deployment name (or deployment name regex). (BTW, I understand this design is not random, there were reasons to organize it this way but I'd like to raise my concerns). Which is a common practice in a relational database design but our management model is not as sophisticated, yet :) We don't have: - foreign key constraints (again, yet, I know Brian is going to look into that); - no cascade-delete; - no queries (e.g. by node attributes). CREATING A LINK AND LOOKING FOR IT To create a link between an overlay and a deployment, I have to come up with a name for it, which has to be unique, like a primary key. Well, I chose the format overlay_name-deployment_name. Then, in CLI, I rely on this format to search for the link(s), since searching by resource attributes turns out to be much more complicated, although possible. Actually, even searching using this naming format by deployment name or an overlay name is not that smooth. So, the CLI now expects a specific naming format. Taking into account that the CLI is not the only management tool and that any application or user can manage things "manually", it'd be good for all the users and tools to agree on the naming format, which is not practical. REMOVING A DEPLOYMENT Until now it was about removing only the deployment. Now, not to run into inconsistencies in the model, the "third table" has to be searched for references and cleaned up if found. Removing an overlay leads to the same consequences, of course, which is unavoidable anyway. But I think we could re-organize the model to minimize the risks or running into inconsistencies and simplify management. ALTERNATIVE STRUCTURES I discussed these issues with Emanuel, who agreed and had in mind another idea to represent this in the model, which I actually find more logical and elaborate. I'll let him follow up and describe it in details. Thanks, Alexey