again, thanks! it'll be a while before it will be a problem, main thing is that we don't start doing something now that will break the mechanism then ...
On 6/15/06, Jess Robinson <[EMAIL PROTECTED]> wrote: > > Or you could look at the versioning branch of DBIx::Class, which will > handle all that for you. See VERSIONING_SKETCH in the -current branch for > a summary of what it will be able to do. > > Jess > > > On Wed, 14 Jun 2006, Daniel McBrearty wrote: > > > thanks! > > > > On 6/13/06, Richard Jolly <[EMAIL PROTECTED]> wrote: > >> On 12 Jun 2006, at 20:53, Daniel McBrearty wrote: > >> > >>> I'm currently migrating engoi from the current mysql schema to pg. > >>> Along the way, the schema is changing shape quite drastically, for > >>> various reasons. > >>> > >>> Here's how I'm doing it: > >>> > >>> 1. writing the new pg schema in a single file (pg.sql) > >>> 2. writing a migrate script that gets data out of the old db and into > >>> the new. > >>> 3. testing, updating the cat app > >>> 4. repeat for a new chunk of original schema. > >>> > >>> Everything uses DBIx::Class now (can't believe I was rolling my own > >>> ORM a year back ...) > >>> > >>> My question : given that this new schema will not be set in stone (it > >>> will get added to as we add new functions, though hopefully we will > >>> not have to rehash the whole thing again) - am I making life harder > >>> than needs be for future? > >>> > >>> What I can see happening for future is this : > >>> > >>> 1. dev a new feature, along with a scripts to add to and maybe > >>> populate the schema as needed. > >>> 2. when ready use scripts to update the prod server. > >>> > >>> I just had a speed read of the cookbook for DBIx, and saw some stuff > >>> about managing schema versioning. I'm just wondering if my current way > >>> of working is going to be something I'm going to regret down the line > >>> ... to ge honest I don't have too much time to read all the docs, and > >>> I'm not sure if I'd get all teh implications on a first reading anyhow > >>> ... > >> > >> Take a look at DBIx::Migration. That would give you more management of > >> updates, and, importantly, rollbacks. It is not a magic module - it > >> basically just manages a collection of update and rollback sql scripts > >> that you have to write. > >> > >> It could be used in conjunction with the DBIC method. The > >> DBIx::Class::Manual::Cookbook method relies on sqlt-diff (from > >> SQL::Translator) to produce a "diff" between two schemas as a > >> collection of update table statements. These diffs could be used as a > >> basis for the DBIx::Migration sql scripts. The schema files themselves > >> can be generated from DBIC. > >> > >> Richard > >> > >> > >> _______________________________________________ > >> List: [email protected] > >> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > >> Searchable archive: http://www.mail-archive.com/[email protected]/ > >> Dev site: http://dev.catalyst.perl.org/ > >> > > > > > > -- > > Daniel McBrearty > > email : danielmcbrearty at gmail.com > > www.engoi.com : the multi - language vocab trainer > > BTW : 0873928131 > > > > _______________________________________________ > > List: [email protected] > > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > > Searchable archive: http://www.mail-archive.com/[email protected]/ > > Dev site: http://dev.catalyst.perl.org/ > > > > > > _______________________________________________ > List: [email protected] > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/[email protected]/ > Dev site: http://dev.catalyst.perl.org/ > -- Daniel McBrearty email : danielmcbrearty at gmail.com www.engoi.com : the multi - language vocab trainer BTW : 0873928131 _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
