On Mar 17, 8:03 pm, Jeremy Evans <[email protected]> wrote: > > As for my question: what exactly the plugin is doing that makes > > everything work -- and how can I do it myself, without using the > > plugin? > > The migration plugin just gives users a fairly simple ActiveRecord- > like way of managing changes to schema. Migrations themselves are > fairly pointless unless you are using the Migrator (which handles > multiple migrations at once). Instead of a single migration, you are > better off just calling the schema methods directly on the Database > object.
Thank you for the explanation. I wish I had been more specific about to which plugin I was referring. My question was supposed to have regarded the class_table_inheritance plugin, and more generally, any plugin added to a given model, and how it enables such a model to "know" about its dataset. That's okay though -- the remainder of your responses sufficiently answers my question. > > I'm trying to look at the source code for > > Sequel::Model::ClassMethods.plugin to see if there's some easy routine > > I can explicitly apply post-migration-application to my pre-migration- > > application-defined models. > > You can't. You should be defining your models after all schema > changes have been made. Usually it's fairly simple to change the load > order in your app so models are loaded after migrations have been > run. If you can't do so, just be sure to call set_dataset on all of > your models after the migrations have been run. With the subclasses > plugin, this is fairly easy. You're absolutely right. It appears that there may be a friction between what I wish to accomplish, and my understanding of the Sequel design. Basically, I wanted to create reference demonstrations of particular components of my system in isolation. This demonstration includes the following steps: 1.) Tear down any existing database and schema from previous invocations of the demo. 2.) Re-create the database, and respecify the schema. 3.) Define models. 4.) Invoke demo routines for models defining individual components. I should probably be using whatever support Sequel probably has for unit testing frameworks -- but at the risk of sounding lazy or obstinate, I am loathe to introduce unit testing to my project at this stage of its development. It is still unclear if I am even on the right path in terms of its design. > > That the current situation (of having to define one's models strictly > > after a migration) is by design is recognizable, but I am having > > trouble understanding it. This makes me want to try to work around it > > for the purposes of my application. > > Trouble understanding the reason for it? Sequel executes a lot of > code when the classes are defined. This includes parsing the database > schema to get the columns and types. This is why they should be > loaded after all changes to the database have been made. Otherwise, > let's say you add a column in a migration after creating the related > model class. The model class will then not have that migration > defined unless you call set_dataset to reinitialize things. Jeremy, thank you again for taking the time to explain this excellent software. Would you accept a small donation for the invaluable service you are providing people like me in this forum and in the Sequel project? If so, please provide a link or a PayPal e-mail address. Thank you, -Nels -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
