I''m playing around with engines, and want to see if I can get
migrations working with them. According to rake --tasks, the migrate
task will "migrate the database according to the migrate scripts in
db/migrate (only supported on PG/MySQL)." I assumed it would just
look in the current dir for db/migrate, but it doesn''t seem to be.
Here''s the layout of my app:
myproject
|- db
|- migrate
|- vendor
|- plugins
|- myengine
|- db
|- migrate
if I cd to vendor/plugins/myengine and run "rake migrate", it ignores
the files in ./db/migrate. However if I copy them up to
myproject/db/migrate, it finds them fine. So my first question is how
does rake know to use RAILS_ROOT to begin with? I don''t see any
reason why it wouldn''t act in the current directory. Second, how do I
get it to run migrate on the migrations beneath the current directory?
Thanks,
Pat
Running migrations from external code sources is going to involve a LOT of trust. I can see how the workflow might ideally be very convenient, but I would *strongly* suggest that it''s better for you to have all of the migrations stuff under your total control. It''s not that I''m saying you absolutely shouldn''t... just that when you''re actually talking about your DB, the precious data in the middle of your Totally Sweet Rails App, I wouldn''t trust *anyone* to screw around with the schema at all. In other words, the DB schema provided with engines should only really be used for bootstrapping and for reference, and manually integrating it with your existing migrations will probably make your life much easier in the long-term. DB schemas shouldn''t change between minor versions of engines (or any code that is in beta), so if you stick to a single release of, say, the login engine, you shouldn''t have to deal with schema changes, ever (oh, for an ideal world...). - james On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m playing around with engines, and want to see if I can get > migrations working with them. According to rake --tasks, the migrate > task will "migrate the database according to the migrate scripts in > db/migrate (only supported on PG/MySQL)." I assumed it would just > look in the current dir for db/migrate, but it doesn''t seem to be. > Here''s the layout of my app: > myproject > |- db > |- migrate > |- vendor > |- plugins > |- myengine > |- db > |- migrate > > if I cd to vendor/plugins/myengine and run "rake migrate", it ignores > the files in ./db/migrate. However if I copy them up to > myproject/db/migrate, it finds them fine. So my first question is how > does rake know to use RAILS_ROOT to begin with? I don''t see any > reason why it wouldn''t act in the current directory. Second, how do I > get it to run migrate on the migrations beneath the current directory? > > Thanks, > Pat > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I was thinking more like using migrations to manage the database as the app progresses...but if I''m just working on the engine, then obviously I don''t need to upgrade any schemas, so I''m free to just wipe the db as necessary. On 11/15/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Running migrations from external code sources is going to involve a > LOT of trust. I can see how the workflow might ideally be very > convenient, but I would *strongly* suggest that it''s better for you to > have all of the migrations stuff under your total control. > > It''s not that I''m saying you absolutely shouldn''t... just that when > you''re actually talking about your DB, the precious data in the middle > of your Totally Sweet Rails App, I wouldn''t trust *anyone* to screw > around with the schema at all. > > In other words, the DB schema provided with engines should only really > be used for bootstrapping and for reference, and manually integrating > it with your existing migrations will probably make your life much > easier in the long-term. DB schemas shouldn''t change between minor > versions of engines (or any code that is in beta), so if you stick to > a single release of, say, the login engine, you shouldn''t have to deal > with schema changes, ever (oh, for an ideal world...). > > - james > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I''m playing around with engines, and want to see if I can get > > migrations working with them. According to rake --tasks, the migrate > > task will "migrate the database according to the migrate scripts in > > db/migrate (only supported on PG/MySQL)." I assumed it would just > > look in the current dir for db/migrate, but it doesn''t seem to be. > > Here''s the layout of my app: > > myproject > > |- db > > |- migrate > > |- vendor > > |- plugins > > |- myengine > > |- db > > |- migrate > > > > if I cd to vendor/plugins/myengine and run "rake migrate", it ignores > > the files in ./db/migrate. However if I copy them up to > > myproject/db/migrate, it finds them fine. So my first question is how > > does rake know to use RAILS_ROOT to begin with? I don''t see any > > reason why it wouldn''t act in the current directory. Second, how do I > > get it to run migrate on the migrations beneath the current directory? > > > > Thanks, > > Pat > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Pat, you might want to check out the migrations stuff that I just added to the developer branch of Engines; I posted to the list yesterday about it. Very much inspired by your conversation on IRC :) - james On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I was thinking more like using migrations to manage the database as > the app progresses...but if I''m just working on the engine, then > obviously I don''t need to upgrade any schemas, so I''m free to just > wipe the db as necessary. > > > On 11/15/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Running migrations from external code sources is going to involve a > > LOT of trust. I can see how the workflow might ideally be very > > convenient, but I would *strongly* suggest that it''s better for you to > > have all of the migrations stuff under your total control. > > > > It''s not that I''m saying you absolutely shouldn''t... just that when > > you''re actually talking about your DB, the precious data in the middle > > of your Totally Sweet Rails App, I wouldn''t trust *anyone* to screw > > around with the schema at all. > > > > In other words, the DB schema provided with engines should only really > > be used for bootstrapping and for reference, and manually integrating > > it with your existing migrations will probably make your life much > > easier in the long-term. DB schemas shouldn''t change between minor > > versions of engines (or any code that is in beta), so if you stick to > > a single release of, say, the login engine, you shouldn''t have to deal > > with schema changes, ever (oh, for an ideal world...). > > > > - james > > > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I''m playing around with engines, and want to see if I can get > > > migrations working with them. According to rake --tasks, the migrate > > > task will "migrate the database according to the migrate scripts in > > > db/migrate (only supported on PG/MySQL)." I assumed it would just > > > look in the current dir for db/migrate, but it doesn''t seem to be. > > > Here''s the layout of my app: > > > myproject > > > |- db > > > |- migrate > > > |- vendor > > > |- plugins > > > |- myengine > > > |- db > > > |- migrate > > > > > > if I cd to vendor/plugins/myengine and run "rake migrate", it ignores > > > the files in ./db/migrate. However if I copy them up to > > > myproject/db/migrate, it finds them fine. So my first question is how > > > does rake know to use RAILS_ROOT to begin with? I don''t see any > > > reason why it wouldn''t act in the current directory. Second, how do I > > > get it to run migrate on the migrations beneath the current directory? > > > > > > Thanks, > > > Pat > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I saw the announcement, thanks for putting it up. That wasn''t you I was talking with, was it? I''d feel pretty stupid referring to "James Adam" if I was speaking with you :) Anyway I''ll mess around with it, see if there are any problems. Any clue about the problem with the LoginEngine not rolling back changes when an email can''t be delivered? I spent a long time trying to figure out why that test was failing and am just stumped. Pat On 11/17/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Pat, you might want to check out the migrations stuff that I just > added to the developer branch of Engines; I posted to the list > yesterday about it. Very much inspired by your conversation on IRC :) > > - james > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I was thinking more like using migrations to manage the database as > > the app progresses...but if I''m just working on the engine, then > > obviously I don''t need to upgrade any schemas, so I''m free to just > > wipe the db as necessary. > > > > > > On 11/15/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Running migrations from external code sources is going to involve a > > > LOT of trust. I can see how the workflow might ideally be very > > > convenient, but I would *strongly* suggest that it''s better for you to > > > have all of the migrations stuff under your total control. > > > > > > It''s not that I''m saying you absolutely shouldn''t... just that when > > > you''re actually talking about your DB, the precious data in the middle > > > of your Totally Sweet Rails App, I wouldn''t trust *anyone* to screw > > > around with the schema at all. > > > > > > In other words, the DB schema provided with engines should only really > > > be used for bootstrapping and for reference, and manually integrating > > > it with your existing migrations will probably make your life much > > > easier in the long-term. DB schemas shouldn''t change between minor > > > versions of engines (or any code that is in beta), so if you stick to > > > a single release of, say, the login engine, you shouldn''t have to deal > > > with schema changes, ever (oh, for an ideal world...). > > > > > > - james > > > > > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > I''m playing around with engines, and want to see if I can get > > > > migrations working with them. According to rake --tasks, the migrate > > > > task will "migrate the database according to the migrate scripts in > > > > db/migrate (only supported on PG/MySQL)." I assumed it would just > > > > look in the current dir for db/migrate, but it doesn''t seem to be. > > > > Here''s the layout of my app: > > > > myproject > > > > |- db > > > > |- migrate > > > > |- vendor > > > > |- plugins > > > > |- myengine > > > > |- db > > > > |- migrate > > > > > > > > if I cd to vendor/plugins/myengine and run "rake migrate", it ignores > > > > the files in ./db/migrate. However if I copy them up to > > > > myproject/db/migrate, it finds them fine. So my first question is how > > > > does rake know to use RAILS_ROOT to begin with? I don''t see any > > > > reason why it wouldn''t act in the current directory. Second, how do I > > > > get it to run migrate on the migrations beneath the current directory? > > > > > > > > Thanks, > > > > Pat > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I''m "lazyat0m", normally, so no - I was lurking ;) I''m still stumped by that issue - when I try working with it in the console, the roll-back happens, but it just never seems to work when testing! :-S - james On 11/17/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I saw the announcement, thanks for putting it up. That wasn''t you I > was talking with, was it? I''d feel pretty stupid referring to "James > Adam" if I was speaking with you :) > > Anyway I''ll mess around with it, see if there are any problems. > > Any clue about the problem with the LoginEngine not rolling back > changes when an email can''t be delivered? I spent a long time trying > to figure out why that test was failing and am just stumped. > > Pat > > On 11/17/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Pat, you might want to check out the migrations stuff that I just > > added to the developer branch of Engines; I posted to the list > > yesterday about it. Very much inspired by your conversation on IRC :) > > > > - james > > > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I was thinking more like using migrations to manage the database as > > > the app progresses...but if I''m just working on the engine, then > > > obviously I don''t need to upgrade any schemas, so I''m free to just > > > wipe the db as necessary. > > > > > > > > > On 11/15/05, James Adam <james.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > Running migrations from external code sources is going to involve a > > > > LOT of trust. I can see how the workflow might ideally be very > > > > convenient, but I would *strongly* suggest that it''s better for you to > > > > have all of the migrations stuff under your total control. > > > > > > > > It''s not that I''m saying you absolutely shouldn''t... just that when > > > > you''re actually talking about your DB, the precious data in the middle > > > > of your Totally Sweet Rails App, I wouldn''t trust *anyone* to screw > > > > around with the schema at all. > > > > > > > > In other words, the DB schema provided with engines should only really > > > > be used for bootstrapping and for reference, and manually integrating > > > > it with your existing migrations will probably make your life much > > > > easier in the long-term. DB schemas shouldn''t change between minor > > > > versions of engines (or any code that is in beta), so if you stick to > > > > a single release of, say, the login engine, you shouldn''t have to deal > > > > with schema changes, ever (oh, for an ideal world...). > > > > > > > > - james > > > > > > > > On 11/15/05, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I''m playing around with engines, and want to see if I can get > > > > > migrations working with them. According to rake --tasks, the migrate > > > > > task will "migrate the database according to the migrate scripts in > > > > > db/migrate (only supported on PG/MySQL)." I assumed it would just > > > > > look in the current dir for db/migrate, but it doesn''t seem to be. > > > > > Here''s the layout of my app: > > > > > myproject > > > > > |- db > > > > > |- migrate > > > > > |- vendor > > > > > |- plugins > > > > > |- myengine > > > > > |- db > > > > > |- migrate > > > > > > > > > > if I cd to vendor/plugins/myengine and run "rake migrate", it ignores > > > > > the files in ./db/migrate. However if I copy them up to > > > > > myproject/db/migrate, it finds them fine. So my first question is how > > > > > does rake know to use RAILS_ROOT to begin with? I don''t see any > > > > > reason why it wouldn''t act in the current directory. Second, how do I > > > > > get it to run migrate on the migrations beneath the current directory? > > > > > > > > > > Thanks, > > > > > Pat > > > > > _______________________________________________ > > > > > Rails mailing list > > > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > _______________________________________________ > > > > Rails mailing list > > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >