Re: [php-139] Dev Environment: PHP/MySQL version control

From: Scott Hildebrand
Sent on: Wednesday, September 16, 2009 6:36 PM
This is a good idea to some extent, although I would be careful to have it abstracted enough. Like have a global flag that determines which dbs to interact with, and segment your code enough so that each model has an appropriate block of code to handle each schema model. Organize enough at the beginning so you could just turn one off at any time, and all the logic isn't spaghetti code doing everything at once.

--- On Wed, 9/16/09, Avichal Garg <[address removed]> wrote:

From: Avichal Garg <[address removed]>
Subject: Re: [php-139] Dev Environment: PHP/MySQL version control
To: [address removed]
Date: Wednesday, September 16, 2009, 5:27 PM

The "best" way I've seen it handled is to have code that works with
both the old and new schemas and writes to both. Then if you have to
roll back you can and you don't screw up the database. Clearly there's
a big development overhead to do this

We (at Google) only did this in cases where the risk of losing data
was too high and we needed 100% surity that we could roll back if we
needed...for example in the advertising systems that store critical
click and impression data...in which case the development overhead is
worth it

On 9/16/09, Scott Hildebrand <[address removed]> wrote:
> I think version control systems are pretty exclusive to code. If you're
> working with a certain kind of framework like Symfony, the development
> database is auto-generated from YAML files. So essentially schema is
> getting into version control. However once that goes into production
> you're not replacing the database every time you update code. Code can
> change but schema can't without fucking with data... which would be
> unacceptable in most cases.
>
> --- On Wed, 9/16/09, Alan Puccinelli <[address removed]> wrote:
>
> From: Alan Puccinelli <[address removed]>
> Subject: [php-139] Dev Environment: PHP/MySQL version control
> To: [address removed]
> Date: Wednesday, September 16, 2009, 4:14 PM
>
> Has anyone come across a good method for keeping their source code and
> database schema in sychronized version control so that you can roll back
> code and schema simultaneously if need be?
>
> In particular I would be super stoked if there were something out there like
> springloops (www.springloops.com- web based SVN manager) with a web GUI that
> keeps your DBs in sync and allows you to easily deploy from dev to
> production.
>
>
>
> Is this just wishful thinking or has anyone seen it?
>
> -Alan
>
>
>
>
>
>
>
>
> --
>
> Please Note: If you hit "REPLY", your message will be sent to everyone on
> this mailing list ([address removed])
>
> This message was sent by Alan Puccinelli ([address removed]) from The
> San Francisco PHP Meetup Group.
>
> To learn more about Alan Puccinelli, visit his/her member profile
>
> To unsubscribe or to update your mailing list settings, click here
>
>
>
>     Meetup Support: [address removed]
>
>     632 Broadway, New York, NY 10012 USA
>
>
>
>
>
>



--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
http://www.sfphp.org/
This message was sent by Avichal Garg ([address removed]) from The San Francisco PHP Meetup Group.
To learn more about Avichal Garg, visit his/her member profile: http://www.sfphp.org/members/8279265/
To unsubscribe or to update your mailing list settings, click here: http://www.meetup.com/account/comm/
Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA


Our Sponsors

GameSpot.com

GameSpot.com & CBSi provides the facilities our group uses every month.

O'Reilly User Group Program

The O'Reilly User Group Program provides the great books we get monthly.

Other nearby
Meetup Groups
Why these groups?
x

The Meetup Groups shown here are topically similar to The San Francisco PHP Meetup Group.

Groups are more likely to be displayed here if they:

  • have a Meetup scheduled
  • have a high rating
  • have a group photo
  • are "public" and not "private"
  • have shown they are likely to stick around (older than 30 days)