>> First let me say what a breath of fresh air Sequel is after long >> struggles to make ActiveRecord do what I want. > > Thanks. I think one of the reasons for that is the desire to keep > things as simple as possible.
Perhaps I should clarify what I meant there, and where I'm coming from more broadly. The reason I like Sequel it is that it provides a powerful set of abstractions for representing SQL syntax trees in Ruby, and it isn't overly "opinionated" about what sort of object-relational mappings I choose to build ontop of those abstractions. I also feel that it's tantalisingly close to the power of libraries like Python's SQLAlchemy: http://www.sqlalchemy.org/, when it comes to providing a relational algebra engine which can be used as a toolkit to build all sorts of styles of object-relational mapping. If the SQL engine could keep a track of a little bit more database metadata in its representation of SQL syntax trees, it would open up a lot of new possibilities for building abstractions on top of it. Code does speak louder than words though, so I'll have to go through in more detail and attempt an implementation of some of what I describe. I would hope the complexity story wouldn't be as bad as you fear, and I'll happy to live with certain limitations / restrictions on the solution. > Sequel has no way of knowing if b refers to a column in a or c, or > even a table to be added/joined to the dataset later. So maybe a necessary limitation, in the absense of more db introspection, would be that you have to use a full :table__column style column name in order to build an update statement from a joined dataset. That seems fair enough. Another approach could be convert :column to :table__column under the hood in instances where there is just one table in the query, so as to make it easier to disambiguate if joins are added later. Taking it further one could maintain a mapping of dataset column names to physical table/column name pairs, and keep it up to date to the extent possible when performing joins and selects, ruling out certain features when it's not possible. Do realise that adds complexity though. > How do you expect Sequel to know enough to make the right decisions? I was planning on introspecting Sequel's representation of the SQL syntax tree where necessary. Again certain limitations would doubtless have to apply in cases where it doesn't have enough information to go on. The issue with introspection of the db schema though, might be more of an obstacle if not currently supported. > Really, it would be better to switch to a database that sucks less. I won't get sucked into a postgres vs mysql debate here - suffice to say that it's a complex set of trade-offs... > The best way to handle CTI in Sequel is probably using associations, > before or after model callbacks (when a subclass object is saved, save > the superclass associated object as well), and intelligent accessors > (def blah=(x); superclass_object.blah = x; end). With some > metaprogramming it shouldn't be too difficult. I built a plugin for ActiveRecord a while back which took this approach, but the result was a really messy, leaky abstraction that caused a fair few issues for us, hence I was looking for a more elegant way to implement the pattern ontop of a tool that knows more about relational algebra. Appreciate the feedback though. Really I was just looking to get an idea of whether the goals for sequel have any overlap with some of the things I was hoping to do with it. I'll see how far I get when it comes to adding things like multi-table update to Sequel, so long as you're not opposed in theory to the idea :) Cheers, -Matt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
