[jifty-devel] Proposed change to SchemaGenerator

Andrew Sterling Hanenkamp andrew.hanenkamp at boomer.com
Thu Feb 22 18:26:21 EST 2007


I've gotten deeper than that now. I'm trying to decide how much detail
to go into about it. I'll try to keep it short.

Basically, I started down this path in order to fix up column renaming.
It was working in some cases, but not in others. It also didn't
cooperate very well with the "since" and "till" traits for columns.

Since much of the magic behind how columns are built and the tables are
deployed happens in JDBI, it seems that JDBI needs at least a
rudimentary understanding of versions. I think the concept of what the
database/schema version is should be left up to the implementation, but
some of the actual handling almost has to be moved into JDBI to some
extent (and already has with the introduction of "till" and "since").

The solution I've ended up with is not an app_version in
SchemaGenerator, but an app_version that may be implemented in by a
subclass of JDBI::Record. I can make the change to "schema_version", I
just picked "app_version" because the docs in JDBI use the term
"application version", but it should probably be either "schema version"
or "database version". That's an easy change.

My latest changes allow both the creation of accessor/mutator methods
and the deployment of the schema to be based upon the notion of the
database version that the implementation wishes to express. For example,
I've made it so that Jifty passes back the framework->Database->Version
number via the Jifty::Record implementation of app_version.

To make this work with Jifty, I did change when method initialization
takes place. The creation of custom accessors and mutators (i.e., the
COLUMN and set_COLUMN methods) were generated at compile time while
declaring the schema { ... }. Under the new regime, this would happen
later during the very first call to JDBI::Record->new. Without this
change I was running into a chicken-egg problem because schema
declaration needed to know the version, which needed the configuration,
which needed the schema declarations. An alternative would be to delay
model loading until after Jifty::Config has been established, but this
was a simpler solution for now.

Overall, the patches make this work in all circumstances I've tested so
far:

in App::Model::Foo:

column foo => type is 'text', till '0.2.5';
column foo2 => type is 'text', since '0.2.5';

in App::Upgrade:

since '0.2.5' => sub {
  rename table => 'App::Model::Foo',
         column => 'foo',
         to => 'foo2';
};

I've attached patches to both jifty/trunk and Jifty-DBI/trunk. I don't
really feel comfortable committing a change like this back to the trunk
without having other eyes look at it first and tell me it's a good idea
to commit. I have added tests and all tests pass, but it's still a
decent piece of surgery. I was thinking of applying the changes to
virtual-models, though, since that's where must of my work is and is
(slightly) related. I'm not really comfortable doing that without an
okay either.</Hedging>

--
Andrew Sterling Hanenkamp
Interaction Developer
Boomer Consulting, Inc.
 
1.785.537.2358 ext. 17
1.888.266.6375 ext. 17
1.785.537.4545 (fax)
 
610 Humboldt
Manhattan, KS 66502
 
http://www.boomer.com/about/team/andrew-hanenkamp.html
andrew.hanenkamp at boomer.com

-----Original Message-----
From: jifty-devel-bounces at lists.jifty.org
[mailto:jifty-devel-bounces at lists.jifty.org] On Behalf Of Jesse Vincent
Sent: Thursday, February 22, 2007 5:02 PM
To: Nifty apps in a Jiffy
Subject: Re: [jifty-devel] Proposed change to SchemaGenerator




On Thu, Feb 22, 2007 at 10:18:43AM -0600, Andrew Sterling Hanenkamp
wrote:
> Before I push this back into Subversion, I want to make sure it's an 
> okay idea. The patch makes some changes to the behavior of 
> SchemaGenerator, which is fundamental and I want to clear it first.
>  
> I propose to add a new accessor to Jifty::DBI::SchemaGenerator named 
> "app_version" and a constructor argument to set the app_version. The 
> app_version to the constructor is optional.
> 
> If app_version is not given, then it assumes the latest application 
> version, which means that any column with "till" specified in the 
> schema will not be created, but all others will be.

Would it make sense to call it schema_version instead of app_version?

It seems like a reasonable idea. (I was initially quite hesitant about
putting this logic that far down the stack. Traditionally JDBI didn't
understand DB versioning. But on reflection, it seems a good idea.)

-jesse
_______________________________________________
jifty-devel mailing list
jifty-devel at lists.jifty.org
http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jifty-app_version.patch
Type: application/octet-stream
Size: 8424 bytes
Desc: Jifty-app_version.patch
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070222/470034e5/Jifty-app_version-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jifty-DBI-app_version.patch
Type: application/octet-stream
Size: 20381 bytes
Desc: Jifty-DBI-app_version.patch
Url : http://lists.bestpractical.com/pipermail/jifty-devel/attachments/20070222/470034e5/Jifty-DBI-app_version-0001.obj


More information about the jifty-devel mailing list