Matt,

You're essentially talking about an audit trail which you can replay.  
Sounds like something that would fit deep within the guts of 
ActiveRecord but would not necessarily have to be related to Radiant.  
However, you would only have to capture changes (i.e. INSERT, SELECT, 
DELETE).  You would still have to have some way of locking your 
production database.

Richard, you should look into Joyent Slingshot -- Radiant has been 
ported to this mini-platform that allows offline editing and syncing 
with a live database.  It may be the solution you're looking for.

Sean

Matt Hughes wrote:
> Couldn't we extend Radiant so that it trapped all SQL that caused
> update/delete/adds to a script?
>
> * In the beginning, the development and production server have the
> exact same DB with the production server.  Freeze the production
> server so that no changes can happen through /admin.
>
> * Make some changes on the development server.
>
> * Export these changes to a script: "rake db:export:changes" -> changes.sql
>
> * On production server: "mysql radiant_production < changes.sql"
>
>
> I would need to read up more on ActiveRecord and if you are capturing
> just SQL you would have to be using the same DB engine for dev and
> production but does this idea seem feasible?
>
> On Oct 30, 2007 11:18 PM, Daniel Sheppard <[EMAIL PROTECTED]> wrote:
>   
>>> My first thought was to dump the DEV database and import it
>>> into the PROD
>>> database.  The problem with that is I risk overwriting
>>> production data (!!)
>>> and that doesn't help me move non-database resources (i.e.
>>> /public/images/*).
>>>       
>> If you think that overwriting production data is a risk, then
>> you're going about this the wrong way.
>>
>> The only sane way to go about this is to make your production
>> site read-only while you're developing. Any other road WILL
>> lead to madness. Trust me on that.
>>
>> Copy the entire site directory to another location - everything,
>> including public folders - anything that you think you're going
>> to need. Then, duplicate the database, copying it from live to
>> development.
>>
>> To do the database copy I run:
>>
>> mysql -e "drop database radiant_development"
>> mysql -e "create database radiant_development"
>> mysqldump radiant_production | mysql radiant_development
>>
>> I keep all the non-db files on my site under subversion, so I just
>> do a commit in production and a checkout in development. Otherwise,
>> you can just do a simple copy.
>>
>> Then, you do all your development in the development area and when
>> you're happy, reverse the process.
>>
>> I can hear some of you already saying "but we can't leave our
>> production environment locked for that long". If that's the case,
>> just do an initial copy-live-to-test, take note of everything that
>> you do while you develop it and then when you think you've nailed it
>> do a fresh copy-live-to-test and then replay your changes by hand
>> before doing a copy-test-to-live. Alternatively, you could just
>> replay your changes by hand directly into live - but only if you've
>> got an unfaltering belief in yourself.
>>
>> Again, The only way to sanely move changes between two versions that
>> both have modifications in them is by hand.
>>
>> Dan.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Radiant mailing list
>> Post:   [email protected]
>> Search: http://radiantcms.org/mailing-list/search/
>> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>>
>>     
> _______________________________________________
> Radiant mailing list
> Post:   [email protected]
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant
>
>   

_______________________________________________
Radiant mailing list
Post:   [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site:   http://lists.radiantcms.org/mailman/listinfo/radiant

Reply via email to