At the moment, the schema.rb files that I''ve bundled in with engines
have all been accompanied by (hopefully) stark warnings about
conflicting with the applications own unique schema.. in other words
"here''s a convenient way to create the tables that I (the Engine)
expect, but beware that if you run me, I might stomp all over your
other tables like I was king of the world."
It''s an open problem - I''m not 100% up on where the
schema/migrations
focus is heading towards. However, I think it unlikely that Rails will
incorporate features specifically to handle plugin schemas, and even
less likely Engine schemas - not because the Rails core team have
anything against Engines (hopefully), but more in that Engines were
always meant to be something ''on top'' of the base Rails
system. But I
don''t think it''s likely that the schema_info table will
support any
information about plugins/Engines at the moment.
I''m open to any suggestions anyone might have here. It might be useful
to know that in my mind, as development on the LoginEngine (or it''s
successors) proceeds, the links between the controller/helper/view
code and the actual model objects will become weaker and weaker. I
already have a version of the LoginEngine which doesn''t provide a User
model at all, but rather a module which can enhance an ActiveRecord
object with the behaviour the LoginEngine controllers, etc expect -
the best example of something like this is the acts_as_authenticated
module on the Plugins page in the wiki. With this in mind, the onus is
more on the developer himself to provide the schema which supports
these modules, than on any Engine (or Plugin) to define a rigid table
structure.
But like I said - it''s all up in the air. Maybe we can define schema
''modules'' which can mix in columns to table definitions in the
same
way that Ruby modules mix in methods to existing class definitions....
On 11/4/05, Jonathan Younger
<daikini-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> With rails engines each running rake migrate it seems to me that this
> is going to cause some serious conflicts with the existing
> schema_info version table.
>
> The application will have its own version number, each engine will
> have their own version number but the problem is that they all write
> to the same schema_info table.
>
> I haven''t seen any discussion on this yet so not sure if anyone
has
> given it a thought.
>
> I''m thinking that either the schema_info table has a field added
that
> contains the name of the application/engine so each version number is
> specific to the app/engine or we create a new schema_info table for
> each engine. I''d personally prefer the first solution.
>
> Thoughts?
>
> -Jonathan
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>