> On Saturday, May 26, 2012 7:01:48 PM UTC-7, Jeremy Evans wrote: > > On Friday, May 25, 2012 1:28:43 PM UTC-7, Michael Granger wrote: > > Even though it's an unsupported use, subclassing Sequel::Model works quite > > well if you're careful. I do it in several projects in which I want to use > > Sequel::Model, but I can't know where the database is until runtime (e.g., > > connect info is in a config file, etc.). > > This is probably different from what the original poster is asking. In your > case, your model has a backing table, it just isn't known until runtime. He > appears to be requesting a way to use a model without a backing table at all.
Looking back at what I wrote, I didn't explain myself well, but my case is the same as his *in addition* to runtime loading: both of the above cases subclass Sequel::Model, but don't have a backing table, and then all other model classes inherit from it instead of Sequel::Model directly. Mongrel2::Config is the abstract class in the first case, and WordNet::Model in the second. So instead of: ModelClass < (anonymous model class) < Sequel::Model the inheritance ends up being: ConcreteModelClass < (anonymous model class) < AbstractModelClass < Sequel::Model I find it useful to factor up common stuff (e.g., plugins, validations, etc.) into the AbstractModelClass from the concrete subclasses. > Note that the recommended way to handle your case, is to not require the file > containing your model class until runtime. Basically, requiring your library > doesn't require you the file containing your model class. Instead, whenever > you would normally call the #db= method on your model, change that to call a > method that requires the file containing your model class. I am using both of the above Model subclasses in applications that talk to multiple databases through Sequel::Model, so keeping separate subclasses of Sequel::Model for each Database was what worked for me to keep the connections straight. I'll keep better notes the next time I start something with Sequel::Model so I can document what I tried. The pattern I use now is extracted out of at least 4 different experiences creating domain classes, so it's been a few years, and I don't remember what issues led me to do what I did. > It probably is possible to use Sequel::Model completely without a model class > if you do some hacking, but I don't support that. I'm not sure why you'd > want to do that anyway. If the original poster could better explain their > use case, I could probably recommend an alternative. Well, for what it's worth, I've had great success using Sequel::Model this way, and I don't have any support expectations of you should something go wrong. It'd be nice if I could fit what I'm doing into your design for the library, but Sequel is compelling enough that I'm willing to go off the reservation a little if that's what it takes. -- 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.
