I like it as well, especially with the number of dev on the project now. I think by feature is a good idea. I do think there are a number of miscellaneous updates like an index to an existing table that having its own sql file is too much. Maybe we should define when something should be in it's own sql file. For example, if a feature makes this many changes or certain types of changes on the db schema, then it must define its own sql file. One obvious one would be if you introduce a new table, it should be in its own sql file.
As I was saying in a previous email, the current upgrade code does support this way of specifying upgrades. Each upgrade class actually returns an array of sql files, not just one. It's just our current practice that puts all upgrades into one single file. It's not due to the upgrade code. --Alex > -----Original Message----- > From: Soheil Eizadi [mailto:seiz...@infoblox.com] > Sent: Wednesday, September 11, 2013 9:09 AM > To: dev@cloudstack.apache.org > Subject: RE: There is no upgrade path from 4.1.1 to 4.2.0 > > Forgot to comment, I like the idea of having smaller sql files rather than one > large file. -Soheil ________________________________________ > From: Soheil Eizadi [seiz...@infoblox.com] > Sent: Wednesday, September 11, 2013 9:02 AM > To: dev@cloudstack.apache.org > Subject: RE: There is no upgrade path from 4.1.1 to 4.2.0 > > Ordering and dependency needs to be handled with multiple sql files not an > issue with single file. > -Soheil > ________________________________________ > From: Alex Huang [alex.hu...@citrix.com] > Sent: Wednesday, September 11, 2013 8:29 AM > To: dev@cloudstack.apache.org > Subject: RE: There is no upgrade path from 4.1.1 to 4.2.0 > > > > > Why do we even maintain such a thing? DB migration version should not > > be related to the release version. So DB just goes forward in one > > continuous stream, version 42, 43, 44, 45, 46, etc. > > > > So why do we have specific from release to release upgrades? > > Additionally, there shouldn't be a big olde 41to42.sql. There should > > be something 0042-add-important-feature-x.sql, > > 0043-i-added-something-else- splendid.sql. > > > > The multiple sql files upgrade is supported. It was actually the original > intent > with db upgrade but, back when we were a small team, it was easier to just > edit one single file. Now, we can definitely change to that type of > convention. It does mean a lot more sql files but if we add a directory > structure, then it shouldn't be a problem. > > --Alex
