[Catalyst] DBIx::Class and managing schemas

[Daniel McBrearty]

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 <castaway at desert-island.demon.co.uk> 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 <richardjolly at mac.com> 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: Catalyst at lists.rawmode.org
> >> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> >> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> >> 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: Catalyst at lists.rawmode.org
> > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> > Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> > Dev site: http://dev.catalyst.perl.org/
> >
> >
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>


-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131