On 07/31/2013 06:00 AM, Henry Nash wrote: > Hi Adam, > > Wanted to just give you more detail on the issue I keep pressing on > for your change (https://review.openstack.org/#/c/36731/). > > For extensions which create their own "private" tables, I totally get > it. I'd like, however, to understand what happens for a more complex > extension. Let's imagine an (only-partially) hypothetical example of > an extension that does (all of) the following: > > 1) It adds or changes the use of some columns in existing core > tables, and has migrations and code that goes along with that. 2) It > adds a new "private" table, and has all the code to handle that 3) > New APIs etc. to create new REST calls to drive the extension > > It is part 1) in the above that I am trying to understand how we > would implement in this new model. What I am imagining is that the > best way to do 1) is that you would break (at least part of it) out > of the extension and it would be a core patch. This would cover > modifications to core columns and changing any core code to make sure > that such changes were benign to the rest of core (and indeed any > other extensions). Migrations for this part of the schema change > would be in the core repo. Our new extension would then build on > this, have its private new table in its own repo and any unique code > in contrib. Is that how you imagined this working?
I think so. I think that if extensions modify core tables it becomes hard to use more than one of them, and it's also a brittle interface for the extension author. If there is a capability, as you mention, that the core tables/objects need, that should totally be landed in core. If core won't land it, then those pieces of info should just go in a second table. There's actually no information that you can't stick in a second table in sql... > This hypothetical example is, of course, not too far from reality - > the recent change I did for inherited roles > (https://review.openstack.org/#/c/35986/) is an example that comes > close to the above - and it would seem to me that it would be much > safer (from a code dependency point of view) to have the DB changes > done separately and integrated into core - and the extensions just, > in this case, use the advantages of the new schema to provide its > functionality. ++ > Henry > > > _______________________________________________ OpenStack-dev mailing > list [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
