NYCPHP Meetup

[nycphp-talk] talk Digest, Vol 41, Issue 5

Gary Mort garyamort at gmail.com
Mon Mar 8 14:30:35 EST 2010


I'm talking about when working on large applications made up of components,
with a component system built in and a smattering of components included to
make a complete "application".

For example, Joomla:
The Joomla MySQL database contains a table called jos_components where every
component installed in the system has(or should have) an entry in this
table.

It comes with a number of components by default, some of which fall into the
category of must have(and if their not there, bad things happen with other
components depending on them) and some of which are samples that are
frequently replaced(banners and polls).


Now, if you clone the system and do work offline, you then run into an issue
of deployment.  How do you deploy just the changes you made to the
tables....[say you installed and configured 2 new components] without
updating all of them?

Obviously, storing your database schema in your version control system in
some rational format can be used to automate deployment of new code.

However, I like to go in and look at the tables...and if there is some
problem simply coping rows can sometimes help.

So in that case, my opinion is that if one had set the auto increment id and
ensured the base component id's were all under some number[500]...and any
sample components that aren't actually used are in the 500-1000 range, and
finally all other components are above 1000 - then it is a simple matter to
export the data and import[and of course, if you have multiple developers
and gave everyone a different starting increment and offset...ie planning
for 3 developers, you might choose to start production data at 1000, and
each developer at 1001 through 1003.  Set your auto incremement to 6, and
you have room for 2 more developers with no one stepping on each others
toes].

Now deployment is simplified, as developers can simply migrate their data to
the server when ready.

By the same token, if for whatever reason the developer is creating
data[trying different content layouts around], by ensuring their sample data
id's are all set to the sample range, it is simple to setup a build script
which will skip inserts for any data that is outside the range of
production.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100308/0be424e3/attachment.html>


More information about the talk mailing list