Forum: Rails Engines development schema dumping

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bb46488d2c90d51f366cafc776e2b3ad?d=identicon&s=25 Jeff Lindsay (progrium)
on 2006-03-08 12:00
(Received via mailing list)
When using 'rake db_schema_dump' Rails will ignore its own schema
version table, so I'm trying to extend it to ignore engines' as well.
It's a bit tough though because of the way Rails loads the
SchemaDumper class... I'm still playing with it.

Anyway, if I get it working, shall I supply a patch?

Sidenote: I hate Rails making a table for schema info... so I'm doubly
pained to see engines add another for the same reason. I was thinking
it would be nice of engines just extended the Rails table... I don't
think Rails cares of there's extra columns and as long as the app
migration version is the first record, it should keep working.
Thoughts?

--
Jeff Lindsay
http://blogrium.com/
Bb46488d2c90d51f366cafc776e2b3ad?d=identicon&s=25 Jeff Lindsay (progrium)
on 2006-03-08 12:06
(Received via mailing list)
I just realized extended the rails version table would solve the
original issue... which is nice because it looks like it might be
impossible to properly extend the SchemaDumper class from a plugin or
the environment the way the rake task loads it.

I'm a rake noob, can we overwrite rake tasks?

On 3/8/06, Jeff Lindsay <progrium@gmail.com> wrote:
> think Rails cares of there's extra columns and as long as the app
> migration version is the first record, it should keep working.
> Thoughts?
>
> --
> Jeff Lindsay
> http://blogrium.com/
>


--
Jeff Lindsay
http://blogrium.com/
05d703f649ef1d07e78d7b479fb4c4ac?d=identicon&s=25 James Adam (Guest)
on 2006-03-08 12:09
(Received via mailing list)
Patching the schema dump to ignore the engine_schema_info table was on
my hitlist too, but a patch would be more than welcome, so please do
look into that if you can.

W.r.t. just modifying the existing schema_info table, I considered
that but came to the conclusion that it would be the worse of two
evils; adding version information about individual engines would, as
you say, involve adding new columns each time a new engine is
encountered, which then means that the migration system has to ALTER
tables rather than just adding rows. It also puts the engine schema
information at the mercy of whatever processes are playing with the
schema info table, which could concievably be a bad thing. Perhaps I'm
being overprotective here though... I do try and keep an open mind
though - if you wanted to work up a patch for that too, it would
definitely be worthy of discussion.

- james

On 3/8/06, Jeff Lindsay <progrium@gmail.com> wrote:
> think Rails cares of there's extra columns and as long as the app
>
--
* J *
  ~
D8cb8c8cd40ddf0cd05241443a591868?d=identicon&s=25 Duane Johnson (Guest)
on 2006-03-08 22:58
(Received via mailing list)
Perhaps the best solution would be to petition the core to modify the
way this schema_info is created... rather than a single column/single
row table, we could have a key/value pair with which to register
version information.

name varchar(255) default null
version int(11) default null

insert into schema_info (name, version) values ('application', 12);
insert into schema_info (name, version) values ('login_engine', 1);
insert into schema_info (name, version) values ('riki_engine', 3);

Duane Johnson
(canadaduane)
http://blog.inquirylabs.com/
Bb46488d2c90d51f366cafc776e2b3ad?d=identicon&s=25 Jeff Lindsay (progrium)
on 2006-03-09 02:40
(Received via mailing list)
Ah, totally didn't think of that way. :P

On 3/8/06, Duane Johnson <duane.johnson@gmail.com> wrote:
> insert into schema_info (name, version) values ('riki_engine', 3);
> >
> > definitely be worthy of discussion.
> >>
> >> http://blogrium.com/
> >   ~
>
--
Jeff Lindsay
http://blogrium.com/
This topic is locked and can not be replied to.