New Feature Ideas

51 views
Skip to first unread message

Jeremy Evans

unread,
Apr 13, 2010, 2:22:43 PM4/13/10
to sequel-talk
My list of features to add to Sequel is getting a short. I currently
have 3 significant things on it, all of which I'm not sure are worth
the effort:

1) Extensions for PostgreSQL array and hstore types
2) Support for specifying isolation levels in transactions
3) Support for two-phase transactions

Does anyone need/want any of the above features? Does anyone have any
other ideas for features that they would like added to Sequel?

Jeremy

Adrian Madrid

unread,
Apr 13, 2010, 4:41:51 PM4/13/10
to seque...@googlegroups.com
Well, if you want (crazy) ideas how about an EventMachine Sequel port that uses fibers to keep it easy to use? 


Adrian Madrid
My eBiz, Senior Developer
3082 W. Maple Loop Dr
Lehi, UT 84043
801-341-3824




--
You received this message because you are subscribed to the Google Groups "sequel-talk" group.
To post to this group, send email to seque...@googlegroups.com.
To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.


Shawn

unread,
Apr 13, 2010, 6:39:42 PM4/13/10
to sequel-talk
Jeremy,

You've done a great job maintaining and expanding this library. At
this point, I think it needs adoption and community more than new
features. With Rails 3 now supporting ORM choice, Sequel has an
opportunity and a challenge: Rails now allows ORM choice, and
ActiveRecord AREL is claiming Sequel's long-time features as its own.
It's an excellent time to make the case for Sequel by improving its
web presence and online promotion, including:

* A new web site to organize all the docs and examples in one place
* More documentation: entry-level and advanced, from intro to
comprehensive
* An updated/more attractive logo (these things do influence
perception)

I'd be happy to help with this, but I may not be able to contribute a
lot until next month.

Shawn

> > sequel-talk...@googlegroups.com<sequel-talk%2Bunsubscribe@googlegr oups.com>

Aman Gupta

unread,
Apr 13, 2010, 7:09:46 PM4/13/10
to seque...@googlegroups.com
I have a list of bugs and issues, mostly with Rails3 integration, that
I've been unable to commit time to. I would love to see an official
rails3_sequel plugin that brings Sequel integration to the same level
as Datamapper and ActiveRecord.

Aman

> To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.

byrnejb

unread,
Apr 14, 2010, 12:21:50 PM4/14/10
to sequel-talk

On Apr 13, 7:09 pm, Aman Gupta <themastermi...@gmail.com> wrote:
> . . . I would love to see an official rails3_sequel plugin that


> brings Sequel integration to the same level as Datamapper and ActiveRecord.
>
>

+1

Jeremy Evans

unread,
Apr 14, 2010, 1:48:25 PM4/14/10
to sequel-talk
On Apr 13, 4:09 pm, Aman Gupta <themastermi...@gmail.com> wrote:
> I have a list of bugs and issues, mostly with Rails3 integration, that
> I've been unable to commit time to. I would love to see an official
> rails3_sequel plugin that brings Sequel integration to the same level
> as Datamapper and ActiveRecord.

I'll be happy to give official support to such a plugin. However, at
this point I don't plan to work on such a plugin myself, though I'll
definitely help anyone who is interested in creating one.

Jeremy

Jeremy Evans

unread,
Apr 14, 2010, 2:30:46 PM4/14/10
to sequel-talk
On Apr 13, 3:39 pm, Shawn <svicalifor...@gmail.com> wrote:
> Jeremy,
>
> You've done a great job maintaining and expanding this library.  At
> this point, I think it needs adoption and community more than new
> features.  With Rails 3 now supporting ORM choice, Sequel has an
> opportunity and a challenge: Rails now allows ORM choice, and
> ActiveRecord AREL is claiming Sequel's long-time features as its own.
> It's an excellent time to make the case for Sequel by improving its
> web presence and online promotion, including:
>
> * A new web site to organize all the docs and examples in one place

http://sequel.rubyforge.org/documentation.html pretty much does this.
I'm certainly willing to consider design changes to make it more user
friendly, though I'm not sure what they'd be.

> * More documentation: entry-level and advanced, from intro to
> comprehensive

Introductory documentation is Sequel's weakest area, IMO. The RDoc
documentation is fairly comprehensive, but admittedly terse in a lot
of areas.

Unfortunately, people are not specific when they ask for introductory
documentation, and not being a beginner, I'm not sure what the basic
stumbling blocks for new users are. If you could give a rough outline
of the documentation you'd like to see, I could probably work on it.

> * An updated/more attractive logo (these things do influence
> perception)

Not being a graphic designer myself, this isn't something I'm
qualified to do. However, if someone were to provide a better logo, I
would not have a problem changing.

> I'd be happy to help with this, but I may not be able to contribute a
> lot until next month.

I would definitely appreciate the help.

Thanks,
Jeremy

mooman

unread,
Apr 14, 2010, 2:52:43 PM4/14/10
to sequel-talk
I've been working with Rails 3 and Sequel for a bit now, and would be
interested in helping out with the integration.

Aman, if you have already started something, please let me know how i
continue on your work. Didn't see anything on your github, or maybe im
blind...

mooman

unread,
Apr 14, 2010, 2:58:27 PM4/14/10
to sequel-talk
Jeremy... thanks for the awesome job you've been doing with Sequel
updates. As one person's point of view (mine): we use PostgreSQL as
our primary DB at work (and we love it). We do use transaction
isolation level some times, but not very often. We tend not to store
"multivalue" in our fields, though there were plenty of times that we
think that is useful, but Dr. Codd might have frowned at us. So we
hardly use that. But i think would be super cool to see something like
that in Sequel, if it's worth the effort...

mooman

unread,
Apr 14, 2010, 3:03:47 PM4/14/10
to sequel-talk
> Introductory documentation is Sequel's weakest area, IMO. The RDoc
> documentation is fairly comprehensive, but admittedly terse in a lot
> of areas.
>

I was (and still is in some aspect) a beginner with Sequel, and i
would agree that it took me a bit to understand sequel. Could also be
my bias background in ActiveRecord (the old one).

Let me try to recall what i was stumbling on the most...


On Apr 14, 11:30 am, Jeremy Evans <jeremyeva...@gmail.com> wrote:
> On Apr 13, 3:39 pm, Shawn <svicalifor...@gmail.com> wrote:
>
> > Jeremy,
>
> > You've done a great job maintaining and expanding this library.  At
> > this point, I think it needs adoption and community more than new
> > features.  With Rails 3 now supporting ORM choice, Sequel has an
> > opportunity and a challenge: Rails now allows ORM choice, and
> > ActiveRecord AREL is claiming Sequel's long-time features as its own.
> > It's an excellent time to make the case for Sequel by improving its
> > web presence and online promotion, including:
>
> > * A new web site to organize all the docs and examples in one place
>

> http://sequel.rubyforge.org/documentation.htmlpretty much does this.

Michael Lang

unread,
Apr 14, 2010, 3:16:20 PM4/14/10
to seque...@googlegroups.com
Introductory documentation is Sequel's weakest area, IMO.  The RDoc
documentation is fairly comprehensive, but admittedly terse in a lot
of areas.

I agree.
 
Unfortunately, people are not specific when they ask for introductory
documentation, and not being a beginner, I'm not sure what the basic
stumbling blocks for new users are.  If you could give a rough outline
of the documentation you'd like to see, I could probably work on it.

Nuances of the library are what falls through the terse/dense documentation we have now.  I've been heavily using Sequel for about 18 months now and my understanding of both Ruby and Sequel has grown exponentially in that time.  Believe it or not, Sequel has taught me a lot of Ruby.  The following are just some memorable events along my way to mastering Sequel.

One of the biggest mistakes I've made is calling update dataset before adding a filter call. 

That is,
    DB[:patients].update(:code => 5).filter(:chart => 1234)

is not the same as:
    DB[:patients].filter(:chart => 1234).update(:code => 5)

The select construct is so easy to mix up the order of things, its not too hard to imagine a beginner not knowing the real rules to ordering of various calls and their ramification.  Covering how to correctly construct these calls and what the ramifications are would help the beginner that is starting to grok sequel along a little better.

Better coverage of the fact that as you chain each dataset method calls, you're getting back a cloned dataset (recent sequel-talk thread) so that each is always mutable.  I never quite realized this was happening, but now that I know, it helps me understand how Sequel works a lot better.

Expanding explanation of what's going on with Virtual Rows.  Better "common usage" examples of the virtual rows that isn't all packed into one table.

That last one actually brings up an idea....what about some documentation that takes a tutorial approach to demonstrating Sequel's usage.

One other thing, although there's lots of documentation on the main site, going from one theme to another is disorienting.  So finding a way to make generated rdocs, and hand-written docs a bit more alike would help a lot.  If the hand-written docs had hrefs back to the rdocs (or vice versa) to aid jumping to/from pages/sections, that would be very beneficial to exploring the docs more.  When I get lost in the docs, I drop back to Google and hunt for stuff rather than staying within the documentation pages and trying to click the many auto-generated links.


Michael
--
http://codeconnoisseur.org

Jeremy Evans

unread,
Apr 14, 2010, 5:48:08 PM4/14/10
to sequel-talk

Thank you very much for providing specific examples of things that
need to be improved. I'll start with your suggestions, but I
encourage other people to submit specific documentation improvement
suggestions. As always, I'll happily accept documentation patches
too.

I'll state for the record that improving Sequel's documentation is at
the top of my todo list, and it's what I'll be working on for at least
the near future.

Jeremy

John Firebaugh

unread,
Apr 14, 2010, 6:02:19 PM4/14/10
to seque...@googlegroups.com
I remember having a hard time finding basic documentation for models,
particularly model associations. There's some documentation in the
README, but I was looking for a guide linked to from
http://sequel.rubyforge.org/documentation.html that specifically
covered those areas in a bit more depth. I felt like there was a gap
there between what's in the README and what's in the rdocs,
particularly since the relevant rdocs are partitioned between class,
instance, and association class methods in a way that makes it
difficult for a newcomer to get an overall grasp on models.

Jeremy Evans

unread,
Apr 14, 2010, 6:30:01 PM4/14/10
to sequel-talk
On Apr 14, 3:02 pm, John Firebaugh <john.fireba...@gmail.com> wrote:
> I remember having a hard time finding basic documentation for models,
> particularly model associations. There's some documentation in the
> README, but I was looking for a guide linked to fromhttp://sequel.rubyforge.org/documentation.htmlthat specifically

> covered those areas in a bit more depth. I felt like there was a gap
> there between what's in the README and what's in the rdocs,
> particularly since the relevant rdocs are partitioned between class,
> instance, and association class methods in a way that makes it
> difficult for a newcomer to get an overall grasp on models.

True. I should probably add a basic associations RDoc page in
addition to the current advanced associations RDoc page. Added to the
todo list.

Jeremy

Shawn

unread,
Apr 14, 2010, 8:53:42 PM4/14/10
to sequel-talk
Here's something I'd love to do. I would like to traverse several
associations and select all the matching model objects from the last
model in the chain, without getting the results for the other tables.
No combined results, no graphs, just model objects from the last table
in the join. And I'd like this to happen in just one SQL query.

modelA_object.assocB_dataset.assocC_dataset.assocD_dataset.all

#=>
SELECT tableD.*
FROM tableB
JOIN tableC ON (...)
JOIN tableD ON (...)
WHERE tableB.tableA = #{modelA_object.id}

(modified by any conditions, orders, or other options of the
associations involved)

This may require making datasets "model-aware," meaning aware of the
model from which they originated, so they can access the model's
associations and other methods. This might be useful in other cases
too; I've found myself wishing that datasets had model-awareness on
more than one occasion.

Shawn

Jeremy Evans

unread,
Apr 14, 2010, 10:21:15 PM4/14/10
to sequel-talk
On Apr 14, 5:53 pm, Shawn <svicalifor...@gmail.com> wrote:
> Here's something I'd love to do.  I would like to traverse several
> associations and select all the matching model objects from the last
> model in the chain, without getting the results for the other tables.
> No combined results, no graphs, just model objects from the last table
> in the join.  And I'd like this to happen in just one SQL query.
>
> modelA_object.assocB_dataset.assocC_dataset.assocD_dataset.all
>
> #=>
> SELECT tableD.*
>   FROM tableB
>   JOIN tableC ON (...)
>   JOIN tableD ON (...)
>  WHERE tableB.tableA = #{modelA_object.id}
>
> (modified by any conditions, orders, or other options of the
> associations involved)
>
> This may require making datasets "model-aware," meaning aware of the
> model from which they originated, so they can access the model's
> associations and other methods.  This might be useful in other cases
> too; I've found myself wishing that datasets had model-awareness on
> more than one occasion.

Model datasets are already model aware, as they have a model method
that returns the related model (see
http://sequel.rubyforge.org/rdoc/classes/Sequel/Model/DatasetMethods.html),
with association datasets also being aware of the related object and
the related association reflection (http://sequel.rubyforge.org/rdoc/
classes/Sequel/Model/Associations/AssociationDatasetMethods.html).

Note that the many_through_many plugin can handle associations through
multiple join tables, though it's up to you to set any conditions,
orders, or other options specific to such an association.

You can already get something similar with your existing associations
using:

ModelD.eager_graph(:ModelC=>:ModelB).filter(:ModelB__ModelA_id=>ModelA_object.id).ungraphed.select(:ModelD.*)

Note that I started with ModelD instead of ModelB. It doesn't have to
be done this way, but it is easier, as otherwise you need to modify
the row_proc for the dataset.

Jeremy

pete

unread,
Apr 15, 2010, 5:39:27 PM4/15/10
to sequel-talk
On Apr 14, 11:30 am, Jeremy Evans <jeremyeva...@gmail.com> wrote:
> On Apr 13, 3:39 pm, Shawn <svicalifor...@gmail.com> wrote:
>
> > Jeremy,
>
> > You've done a great job maintaining and expanding this library.  At
> > this point, I think it needs adoption and community more than new
> > features.  With Rails 3 now supporting ORM choice, Sequel has an
> > opportunity and a challenge: Rails now allows ORM choice, and
> > ActiveRecord AREL is claiming Sequel's long-time features as its own.
> > It's an excellent time to make the case for Sequel by improving its
> > web presence and online promotion, including:
>
> > * A new web site to organize all the docs and examples in one place
>
> http://sequel.rubyforge.org/documentation.htmlpretty much does this.

> I'm certainly willing to consider design changes to make it more user
> friendly, though I'm not sure what they'd be.
>
> > * More documentation: entry-level and advanced, from intro to
> > comprehensive
>
> Introductory documentation is Sequel's weakest area, IMO.  The RDoc
> documentation is fairly comprehensive, but admittedly terse in a lot
> of areas.
>
> Unfortunately, people are not specific when they ask for introductory
> documentation, and not being a beginner, I'm not sure what the basic
> stumbling blocks for new users are.  If you could give a rough outline
> of the documentation you'd like to see, I could probably work on it.
>
> > * An updated/more attractive logo (these things do influence
> > perception)
>
> Not being a graphic designer myself, this isn't something I'm
> qualified to do.  However, if someone were to provide a better logo, I
> would not have a problem changing.
>
> > I'd be happy to help with this, but I may not be able to contribute a
> > lot until next month.
>
> I would definitely appreciate the help.
>
> Thanks,
> Jeremy

Jeremy,

RailsGuides has a few articles on using ActiveRecord that you could
potentially use as inspiration for Sequel. Something like this one for
querying, http://guides.rubyonrails.org/active_record_querying.html,
and this one for associations, http://guides.rubyonrails.org/association_basics.html,
probably would have helped me understand Sequel sooner.

Speaking of AR, it seems like a lot of people migrate to Sequel after
using AR, so a comparison page between AR and Sequel might get people
up to speed faster. I don't really mean "why you should use Sequel
instead", but some documentation of how they differ, equivalent Sequel/
AR idioms, etc.

Jeremy Evans

unread,
Apr 15, 2010, 6:46:57 PM4/15/10
to sequel-talk
On Apr 15, 2:39 pm, pete <p...@peterhiggins.org> wrote:
> RailsGuides has a few articles on using ActiveRecord that you could
> potentially use as inspiration for Sequel. Something like this one for
> querying,http://guides.rubyonrails.org/active_record_querying.html,
> and this one for associations,http://guides.rubyonrails.org/association_basics.html,
> probably would have helped me understand Sequel sooner.

Thanks, I'll give both of those a read.

> Speaking of AR, it seems like a lot of people migrate to Sequel after
> using AR, so a comparison page between AR and Sequel might get people
> up to speed faster. I don't really mean "why you should use Sequel
> instead", but some documentation of how they differ, equivalent Sequel/
> AR idioms, etc.

This sounds like another good idea. I'll add it to my todo list.

Thanks,
Jeremy

--
You received this message because you are subscribed to the Google Groups "sequel-talk" group.
To post to this group, send email to seque...@googlegroups.com.
To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.

Jeremy Evans

unread,
Apr 15, 2010, 6:55:47 PM4/15/10
to sequel-talk
On Apr 14, 12:16 pm, Michael Lang <mwl...@cybrains.net> wrote:
> One of the biggest mistakes I've made is calling update dataset before
> adding a filter call.
>
> That is,
>     DB[:patients].update(:code => 5).filter(:chart => 1234)
>
> is not the same as:
>     DB[:patients].filter(:chart => 1234).update(:code => 5)
>
> The select construct is so easy to mix up the order of things, its not too
> hard to imagine a beginner not knowing the real rules to ordering of various
> calls and their ramification.  Covering how to correctly construct these
> calls and what the ramifications are would help the beginner that is
> starting to grok sequel along a little better.
>
> Better coverage of the fact that as you chain each dataset method calls,
> you're getting back a cloned dataset (recent sequel-talk thread) so that
> each is always mutable.  I never quite realized this was happening, but now
> that I know, it helps me understand how Sequel works a lot better.

Today I committed the first set of documentation patches related to
this area:

http://github.com/jeremyevans/sequel/commit/a39fc8f30438ba07fffaec48013f43fb1ea6b25e
http://github.com/jeremyevans/sequel/commit/c898e4d0c0c1ed1b6c886fec97cfe886f4558c94
http://github.com/jeremyevans/sequel/commit/81af78a6fc306affb258ba7326b02f0bd460a882

Examples of the results are available at:
http://code.jeremyevans.net/sequel-www/rdoc/files/README_rdoc.html
http://code.jeremyevans.net/sequel-www/rdoc/classes/Sequel/Dataset.html
http://code.jeremyevans.net/sequel-www/rdoc/files/doc/dataset_basics_rdoc.html

Please take a look and let me know if I'm heading in the right
direction.

Thanks,
Jeremy

--
You received this message because you are subscribed to the Google Groups "sequel-talk" group.
To post to this group, send email to seque...@googlegroups.com.
To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.

mooman

unread,
Apr 15, 2010, 7:08:49 PM4/15/10
to sequel-talk
Jeremy,

I love the the dataset basics page, especially the table of methods!
Also the "generated sql" additions to the README is super cool, very
clear. Thank you!

One teeny thing caught my eyes: second sentence of the dataset basics,
"... what gives Sequel most of it’s power.", i think you meant "its"
instead of "it's"

> Speaking of AR, it seems like a lot of people migrate to Sequel after
> using AR, so a comparison page between AR and Sequel might get people
> up to speed faster. I don't really mean "why you should use Sequel
> instead", but some documentation of how they differ, equivalent Sequel/
> AR idioms, etc.

Maybe also include AREL stuff? since that's gonna be the new thing and
eveyrthing else is gonna deprecate it seems.

-mooman

On Apr 15, 3:55 pm, Jeremy Evans <jeremyeva...@gmail.com> wrote:
> On Apr 14, 12:16 pm, Michael Lang <mwl...@cybrains.net> wrote:
>
>
>
> > One of the biggest mistakes I've made is calling update dataset before
> > adding a filter call.
>
> > That is,
> >     DB[:patients].update(:code => 5).filter(:chart => 1234)
>
> > is not the same as:
> >     DB[:patients].filter(:chart => 1234).update(:code => 5)
>
> > The select construct is so easy to mix up the order of things, its not too
> > hard to imagine a beginner not knowing the real rules to ordering of various
> > calls and their ramification.  Covering how to correctly construct these
> > calls and what the ramifications are would help the beginner that is
> > starting to grok sequel along a little better.
>
> > Better coverage of the fact that as you chain each dataset method calls,
> > you're getting back a cloned dataset (recent sequel-talk thread) so that
> > each is always mutable.  I never quite realized this was happening, but now
> > that I know, it helps me understand how Sequel works a lot better.
>
> Today I committed the first set of documentation patches related to
> this area:
>
> http://github.com/jeremyevans/sequel/commit/a39fc8f30438ba07fffaec480...http://github.com/jeremyevans/sequel/commit/c898e4d0c0c1ed1b6c886fec9...http://github.com/jeremyevans/sequel/commit/81af78a6fc306affb258ba732...
>
> Examples of the results are available at:http://code.jeremyevans.net/sequel-www/rdoc/files/README_rdoc.htmlhttp://code.jeremyevans.net/sequel-www/rdoc/classes/Sequel/Dataset.htmlhttp://code.jeremyevans.net/sequel-www/rdoc/files/doc/dataset_basics_...

Jeremy Evans

unread,
Apr 15, 2010, 8:48:54 PM4/15/10
to sequel-talk
On Apr 14, 12:16 pm, Michael Lang <mwl...@cybrains.net> wrote:
> Expanding explanation of what's going on with Virtual Rows.  Better "common
> usage" examples of the virtual rows that isn't all packed into one table.

Hopefully this is what you had in mind:

http://github.com/jeremyevans/sequel/commit/3bb63169341ae4f4e0102bf9408bcf0458242879
http://code.jeremyevans.net/sequel-www/rdoc/files/doc/virtual_rows_rdoc.html

Jeremy

--
You received this message because you are subscribed to the Google Groups "sequel-talk" group.
To post to this group, send email to seque...@googlegroups.com.
To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.

Cinaed Simson

unread,
Apr 18, 2010, 7:09:43 PM4/18/10
to seque...@googlegroups.com
I need PostgreSQL arrays.

--

"We are drowning in information and starving for knowledge."

- Rutherford D. Roger

Roland Swingler

unread,
Apr 19, 2010, 6:45:01 AM4/19/10
to sequel-talk
> Does anyone have any other ideas for features that they would like added to Sequel?

Some more MySql specific features would be good (although I'm aware
that there is a slight antipathy towards MySql here). Being able to
write SQL in ruby rather than "String-programming" seems to be a big
benefit of Sequel, so it would be great to be able to do this as much
as possible. Specific things I find myself needing are: "load data
infile", which should be relatively easy to implement, and index
hinting - working with any reasonably sized dataset in MySQL seems to
pretty much require USE INDEX in order to get any sort of decent
performance.

I'm happy to work on these myself when I get time - although I'm not
initially sure how the index hinting would fit in. Maybe as another
method on symbol if you're using the MySQL adapter - something
like :my_table.use_index(:index_name, :for => :join) ?

Also, I'm curious as to whether it would be easy or hard to replace
the usage of the underlying mysql driver with something like
neverblock http://www.espace.com.eg/neverblock/blog/2008/08/28/neverblock-mysql-support/
or mysqlplus http://github.com/oldmoe/mysqlplus - it would be good if
it wasn't just ActiveRecord that got all the Async attention. A good
presentation on all this is here: http://www.igvita.com/2010/04/15/non-blocking-activerecord-rails/

Cheers,
Roland

Jeremy Evans

unread,
Apr 19, 2010, 11:40:20 AM4/19/10
to sequel-talk
On Apr 19, 3:45 am, Roland Swingler <roland.swing...@gmail.com> wrote:
> Some more MySql specific features would be good (although I'm aware
> that there is a slight antipathy towards MySql here). Being able to
> write SQL in ruby rather than "String-programming" seems to be a big
> benefit of Sequel, so it would be great to be able to do this as much
> as possible. Specific things I find myself needing are: "load data
> infile", which should be relatively easy to implement, and index
> hinting - working with any reasonably sized dataset in MySQL seems to
> pretty much require USE INDEX in order to get any sort of decent
> performance.

I'm happy to apply adapter specific patches assuming they come with
specs.

> I'm happy to work on these myself when I get time - although I'm not
> initially sure how the index hinting would fit in. Maybe as another
> method on symbol if you're using the MySQL adapter - something
> like :my_table.use_index(:index_name, :for => :join) ?

Unfortunately, I don't think that any core extensions should be added
for adapter specific behavior. You'll have to write a custom
extension for that.

> Also, I'm curious as to whether it would be easy or hard to replace
> the usage of the underlying mysql driver with something like
> neverblockhttp://www.espace.com.eg/neverblock/blog/2008/08/28/neverblock-mysql-...
> or mysqlplushttp://github.com/oldmoe/mysqlplus- it would be good if
> it wasn't just ActiveRecord that got all the Async attention. A good
> presentation on all this is here:http://www.igvita.com/2010/04/15/non-blocking-activerecord-rails/

Sequel already uses mysqlplus if it is available, falling by to the
standard mysql driver if it is not.

Jeremy

Jeremy Evans

unread,
Apr 19, 2010, 4:20:13 PM4/19/10
to sequel-talk
On Apr 14, 12:16 pm, Michael Lang <mwl...@cybrains.net> wrote:
> That last one actually brings up an idea....what about some documentation
> that takes a tutorial approach to demonstrating Sequel's usage.

You'll have to be a bit more specific about what you want in this
case. I think you might be referring to something like the SteamCode
blog entries on Sequel and Ramaze, but I'm not sure. I'm OK with the
idea of tutorials in general, but there would need to be a pretty
strong focus on teaching Sequel usage as opposed to just solving a
usually contrived problem. I guess this is an area where I'd probably
judge each proposed addition on it's own merits.

> One other thing, although there's lots of documentation on the main site,
> going from one theme to another is disorienting.  So finding a way to make
> generated rdocs, and hand-written docs a bit more alike would help a lot.
> If the hand-written docs had hrefs back to the rdocs (or vice versa) to aid
> jumping to/from pages/sections, that would be very beneficial to exploring
> the docs more.  When I get lost in the docs, I drop back to Google and hunt
> for stuff rather than staying within the documentation pages and trying to
> click the many auto-generated links.

Hopefully http://github.com/jeremyevans/sequel/commit/4bcf03412f9af88fc147e3521f0740ebecdc1a3d
does a good job on tying the guides to the class/method RDocs.
There's probably more places in the class/method RDocs where I should
link to the guides, feel free to send patches if you find any.

Thanks,
Jeremy

--
You received this message because you are subscribed to the Google Groups "sequel-talk" group.
To post to this group, send email to seque...@googlegroups.com.
To unsubscribe from this group, send email to sequel-talk...@googlegroups.com.

Michael Lang

unread,
Apr 19, 2010, 4:38:49 PM4/19/10
to seque...@googlegroups.com
Hi, Jeremy

I've been spending some time reading through the changes you've been making, but have been a little swamped to take time to provide good feedback.  Hopefully, I can provide more feedback later this week!

On the whole, the changes are indeed on the right track and I saw evidence of several points being addressed, which is great.

I'm trying to think more from a whole picture perspective while also recalling some of my earlier struggles while reading through these changes and hope to provide some well-considered feedback. 

One bit of feedback I do have with regards to Virtual Rows documentation, that is also somewhat symptomatic of some of the other pages.  The new format breaks things up a bit and thus is a little less dense, but its still dense.  I think the main reason is simply that Virtual Rows isn't really defined up front.  Three questions come to mind just about anytime I show somebody virtual rows or try to tell 'em what it is (and I still don't do a good job at it):

"what are virtual rows?" 

"why do virtual rows exist?"

and then finally, the bit you do have well documented with the last submissions:

"how do you use virtual rows?"

Just a quick shout out for now...

Michael
--
http://codeconnoisseur.org

Jeremy Evans

unread,
Apr 19, 2010, 7:36:23 PM4/19/10
to sequel-talk
On Apr 19, 1:38 pm, Michael Lang <mwl...@cybrains.net> wrote:
> One bit of feedback I do have with regards to Virtual Rows documentation,
> that is also somewhat symptomatic of some of the other pages.  The new
> format breaks things up a bit and thus is a little less dense, but its still
> dense.  I think the main reason is simply that Virtual Rows isn't really
> defined up front.  Three questions come to mind just about anytime I show
> somebody virtual rows or try to tell 'em what it is (and I still don't do a
> good job at it):
>
> "what are virtual rows?"
>
> "why do virtual rows exist?"

That makes sense. I'll add that to my todo list.

Nate Wiger

unread,
Apr 19, 2010, 9:09:58 PM4/19/10
to sequel-talk
There is stuff like this which is surprising:
http://groups.google.com/group/sequel-talk/browse_thread/thread/7404222dae0686b5/03ccae837966f7ab?lnk=gst&q=before_save#03ccae837966f7ab

While not a "new feature" I do think there is still room to improve
*existing* features of Sequel, especially when Sequel offers very
similar functionality to other ORM's, but has subtleties in its
behavior which can result in unexpected application bugs.

Also, def_dataset_method and other def_ friends are a bit obtuse; a
more friendly "scope" or equivalent term would be nice. They sound
like internal methods I'm not supposed to use as an end-user.

-Nate

Jeremy Evans

unread,
Apr 19, 2010, 10:08:32 PM4/19/10
to sequel-talk
On Apr 19, 6:09 pm, Nate Wiger <nwi...@gmail.com> wrote:
> There is stuff like this which is surprising:http://groups.google.com/group/sequel-talk/browse_thread/thread/74042...

That changed a long time ago (that thread was from 2008). Now
save_changes saves columns modified in before_save. However, if you
don't make any changes at all, save_changes will still do nothing
instead of attempting to save.

> While not a "new feature" I do think there is still room to improve
> *existing* features of Sequel, especially when Sequel offers very
> similar functionality to other ORM's, but has subtleties in its
> behavior which can result in unexpected application bugs.

I suppose that is true with all complex software. When possible, such
undesired behavior should be fixed, and if not possible to fix neatly,
it should certainly be documented.

> Also, def_dataset_method and other def_ friends are a bit obtuse; a
> more friendly "scope" or equivalent term would be nice.  They sound
> like internal methods I'm not supposed to use as an end-user.

Well, subset already performs what I think scope would perform, and I
think subset is a better name. def_dataset_method accurately
describes what is does, while scope does not:

def Album < Sequel::Model
subset(:gold){copies_sold > 500000}
def_dataset_method(:forty_two){42}
end

There's nothing saying that def_dataset_method has to return a
modified dataset, even though that's what it is most commonly used
for. All def_dataset_method does is add a method to the model's
dataset, which is why I think def_dataset_method is a good name.

Most of the other def_ methods are private and probably shouldn't be
used directly, other than maybe def_mutation_method, which should be
used if you add your own dataset methods and want to create mutation
versions of them.

Jeremy

byrnejb

unread,
Apr 20, 2010, 10:59:28 AM4/20/10
to sequel-talk


On Apr 19, 4:20 pm, Jeremy Evans <jeremyeva...@gmail.com> wrote:
>
> You'll have to be a bit more specific about what you want in this
> case.  I think you might be referring to something like the SteamCode
> blog entries on Sequel and Ramaze, but I'm not sure.  I'm OK with the
> idea of tutorials in general, but there would need to be a pretty
> strong focus on teaching Sequel usage as opposed to just solving a
> usually contrived problem.  I guess this is an area where I'd probably
> judge each proposed addition on it's own merits.
>

Might I suggest for consideration a CONTEST?

People submit the description of a real world SQL problem that they
have had and the SQL code they used to solve it. When the period for
problem submissions ends, say 10-14 days, the list members vote for
the top 3 (or more if desired) problems based on the technical issues
raised.

Once the N winning problems are selected then people can submit their
best efforts at solving one or each of the problems using Sequel. They
must also provide a written explanation (can be inline comments) of
what they did and why they did it that way. After another two weeks
or so we vote on the merits of each of the solutions submitted.

The winning pairs of problem and solution become your examples and
both the problem submitter and the Sequel solver get their names
associated with the examples.

The problems submitted MUST have been solved by the submitter using
SQL and the SQl solution provided. I think that this would greatly
reduce the likelihood of the problems being contrived. Further, there
is no need for the problem submitter to necessarily have a Sequel
solution to offer. Likewise there is no need for the Sequel solution
to come from anyone that submitted a problem.

WDYT?

Jeremy Evans

unread,
Apr 20, 2010, 1:46:08 PM4/20/10
to sequel-talk
On Apr 20, 7:59 am, byrnejb <byrn...@harte-lyne.ca> wrote:
> Might I suggest for consideration a CONTEST?
>
> People submit the description of a real world SQL problem that they
> have had and the SQL code they used to solve it.  When the period for
> problem submissions ends, say 10-14 days, the list members vote for
> the top 3 (or more if desired) problems based on the technical issues
> raised.
>
> Once the N winning problems are selected then people can submit their
> best efforts at solving one or each of the problems using Sequel. They
> must also provide a written explanation (can be inline comments) of
> what they did and why they did it that way.  After another two weeks
> or so we vote on the merits of each of the solutions submitted.
>
> The winning pairs of problem and solution become your examples and
> both the problem submitter and the Sequel solver get their names
> associated with the examples.
>
> The problems submitted MUST have been solved by the submitter using
> SQL and the SQl solution provided.  I think that this would greatly
> reduce the likelihood of the problems being contrived.  Further, there
> is no need for the problem submitter to necessarily have a Sequel
> solution to offer. Likewise there is no need for the Sequel solution
> to come from anyone that submitted a problem.
>
> WDYT?

Personally, I don't think response rates would be high enough to
justify the effort involved in setting such a contest up.

However, if you have an interesting Sequel story, I'm happy to accept
guest blog posts for the Sequel blog.

Jeremy

Simon Arnaud

unread,
Apr 21, 2010, 9:44:50 AM4/21/10
to seque...@googlegroups.com
2010/4/13 Jeremy Evans <jeremy...@gmail.com>:
> Does anyone have any
> other ideas for features that they would like added to Sequel?
>
> Jeremy

I think documentation, as mentionned, can really get better.

Here are what I think :
* Do not compare Sequel to another ORM unless it's a page specific to
a comparison or a migration from. I never used AR, and it is confusing
to see it in advanced associations doc, for example.

* clean out README, there's too much in it.

* Have separate pages for models. Basic and advanced would be nice.

* There's a lot of doc in the patch notes, it would be nice if some of
them could be integrated. For example, the :clone thing that was
discussed a few days ago.

* Write a contribute page. I would love to help, but I don't know how.
I understand I can fork GH and then send pull requests, but I'm not
sufficiently skilled to understand everything you expect as base
contribution : code style, tests, ...
Granted, I don't have much time anyway.

* eager load could easily get a page on his own, it's a not a trivial
understanding imo.

As for improvements :

* case syntax, as I mentionned on your blog, is very confusing. I
don't know how it could really be improved though. Maybe replacing it
with else would make it slightly less surprising.

Ideally (for me) :
CASE WHEN
now : {{:a=>[2,3]}=>1}.case(0)
maybe : [ {:a => [2,3]}.then(1), {:b => 4}.then(2)].else(0)

CASE c WHEN
now : {:a=>1, {:b=>2}].case(:d, :c) (typo from the doc)
maybe : :c.when([:a.then(1), :b.then(2)]).else(:d)

dunno if it would fit in sequel though.

* ancestors and descendants (non-rcte) as a keyword would be really nice.
class Node < Sequel::Model
many_to_one :parent, :class=>self
one_to_many :children, :key=>:parent_id, :class=>self
ancestors :parent
descendants :children
end

Node.filter(:id => 34).ancestors.all
Node.filter(:id => 34).descendants.all
Node.filter(:id => 34).descendants(3).all (depth of descendants)


That's all I can think right now, but I'm sure there are a lot of other things.

regards

Simon

Jeremy Evans

unread,
Apr 21, 2010, 11:36:40 AM4/21/10
to sequel-talk
On Apr 21, 6:44 am, Simon Arnaud <maz...@gmail.com> wrote:
> Here are what I think :
> * Do not compare Sequel to another ORM unless it's a page specific to
> a comparison or a migration from. I never used AR, and it is confusing
> to see it in advanced associations doc, for example.

Most Sequel users have some familiarity with AR. However, if any of
the examples currently depend on knowledge of AR to be understandable,
I'll certainly consider adding additional text with more explanation.

> * clean out README, there's too much in it.

Any recommendations on what should be cut?

> * Have separate pages for models. Basic and advanced would be nice.

For associations, there is an advanced page, and I'm working on a
basic page. Most of the very basic model stuff is handled in the
README. Is that the stuff you think should be moved to its own
page?

> * There's a lot of doc in the patch notes, it would be nice if some of
> them could be integrated. For example, the :clone thing that was
> discussed a few days ago.

The basic associations page should cover that particular case, but you
are correct that it is an issue in general.

> * Write a contribute page. I would love to help, but I don't know how.
> I understand I can fork GH and then send pull requests, but I'm not
> sufficiently skilled to understand everything you expect as base
> contribution : code style, tests, ...
> Granted, I don't have much time anyway.

The contribute page already exists (http://sequel.rubyforge.org/
development.html), though I suppose it could be fleshed out. I'm not
too picky on code style or tests, as if I like a patch, I'll happily
change the style or add tests.

> * eager load could easily get a page on his own, it's a not a trivial
> understanding imo.

The advanced associations page has numerous examples of custom eager
loading, assuming that's what you are referring to. This is a case
where it probably helps to have some familiarity with AR, since
Sequel's standard eager loading is fairly similar in concept.

> As for improvements :
>
> * case syntax, as I mentionned on your blog, is very confusing. I
> don't know how it could really be improved though. Maybe replacing it
> with else would make it slightly less surprising.
>
> Ideally (for me) :
> CASE WHEN
> now : {{:a=>[2,3]}=>1}.case(0)
> maybe : [ {:a => [2,3]}.then(1), {:b => 4}.then(2)].else(0)
>
> CASE c WHEN
> now : {:a=>1, {:b=>2}].case(:d, :c) (typo from the doc)
> maybe : :c.when([:a.then(1), :b.then(2)]).else(:d)

It's obviously a matter of taste, but I much prefer the current syntax
over your recommended replacement. I'm sorry if you find it
confusing. It's certainly terse, but should not be difficult to
understand that {{:a=>[2,3]}=>1}.case(0) is translated to "(CASE WHEN
(a IN (2, 3)) THEN 1 ELSE 0 END)".

> * ancestors and descendants (non-rcte) as a keyword would be really nice.
>   class Node < Sequel::Model
>     many_to_one :parent, :class=>self
>     one_to_many :children, :key=>:parent_id, :class=>self
>     ancestors :parent
>     descendants :children
>   end
>
>   Node.filter(:id => 34).ancestors.all
>   Node.filter(:id => 34).descendants.all
>   Node.filter(:id => 34).descendants(3).all (depth of descendants)

ancestors and descendants would only be used for tree structured data,
and as such is a poor fit for something built in. In terms of a non-
rcte tree plugin, sequel-plus (http://github.com/mwlang/sequel_plus)
includes one. As to whether Sequel should ship with a non-rcte tree
plugin, I'd be open to that if there was demand for it.

Jeremy

Jeremy Evans

unread,
Apr 21, 2010, 3:26:18 PM4/21/10
to sequel-talk
On Apr 15, 2:39 pm, pete <p...@peterhiggins.org> wrote:
> RailsGuides has a few articles on using ActiveRecord that you could
> potentially use as inspiration for Sequel. Something like this one for
> querying,http://guides.rubyonrails.org/active_record_querying.html,
> and this one for associations,http://guides.rubyonrails.org/association_basics.html,
> probably would have helped me understand Sequel sooner.

It took a lot of work, but I've added an association basics document:

http://github.com/jeremyevans/sequel/commit/abcad7d983913b15bae50ba61f4c62204ada36ff

You can see the formatted page here:

http://code.jeremyevans.net/sequel-www/rdoc/files/doc/association_basics_rdoc.html

I'd appreciate it if some people could review it and let me know how
helpful it is, and whether anything should be added.

Scott LaBounty

unread,
Apr 21, 2010, 3:40:54 PM4/21/10
to seque...@googlegroups.com
Well ... it certainly would have helped me as I tried to figure things out (in fact it would have saved you answering many of my questions here). I especially like the calling out of the singular/plural usage.

Good stuff.

--
Scott
http://steamcode.blogspot.com/

John Firebaugh

unread,
Apr 21, 2010, 3:44:55 PM4/21/10
to seque...@googlegroups.com
On Wed, Apr 21, 2010 at 12:26 PM, Jeremy Evans <jeremy...@gmail.com> wrote:
You can see the formatted page here:

http://code.jeremyevans.net/sequel-www/rdoc/files/doc/association_basics_rdoc.html

I'd appreciate it if some people could review it and let me know how
helpful it is, and whether anything should be added.

This is super -- exactly what was needed.

Great work.

Jeremy Evans

unread,
Apr 21, 2010, 6:45:29 PM4/21/10
to sequel-talk
On Apr 19, 1:38 pm, Michael Lang <mwl...@cybrains.net> wrote:
> One bit of feedback I do have with regards to Virtual Rows documentation,
> that is also somewhat symptomatic of some of the other pages.  The new
> format breaks things up a bit and thus is a little less dense, but its still
> dense.  I think the main reason is simply that Virtual Rows isn't really
> defined up front.  Three questions come to mind just about anytime I show
> somebody virtual rows or try to tell 'em what it is (and I still don't do a
> good job at it):
>
> "what are virtual rows?"
>
> "why do virtual rows exist?"

I've added some documentation on the purpose for virtual rows:

http://github.com/jeremyevans/sequel/commit/6e1fafca0195da58d983413e83cfb31b1550ba2a
http://code.jeremyevans.net/sequel-www/rdoc/files/doc/virtual_rows_rdoc.html

I'm not sure if I have a good answer for what a virtual row is that
will actually help people. Really, it's a factory class whose
instances use method_missing to return instances of
Sequel::SQL::Expression subclasses. Since that explanation will
generally confound more than enlighten, I decided to leave it out. In
general, the user doesn't need to care what it is as long as they can
use it correctly.

John Firebaugh

unread,
May 3, 2010, 7:32:27 PM5/3/10
to seque...@googlegroups.com
Here's a documentation shortcoming I just came across: I was trying to find the method that returns all tables in the database. I correctly guessed it was Database#tables, but couldn't find it in the Database rdoc. Since the method is only defined by individual adapter-specific subclasses, it doesn't show up there.

I suggest adding documentation in the base class for common adapter-defined methods. Rdoc's :method: directive is good for this: http://ruby-doc.org/ruby-1.9/classes/RDoc/Parser/Ruby.html

Michael Lang

unread,
May 3, 2010, 7:43:47 PM5/3/10
to seque...@googlegroups.com
+1  This is an excellent example of one of my bigger frustration with the docs.  If you don't happen to know what class something was actually implemented in, it is definitely a challenge to track it down.  I think I do better with google and with the rak gem (grep for ruby) than with navigating the docs.
--
http://codeconnoisseur.org

Jeremy Evans

unread,
May 3, 2010, 8:24:05 PM5/3/10
to sequel-talk
On May 3, 4:32 pm, John Firebaugh <john.fireba...@gmail.com> wrote:
> Here's a documentation shortcoming I just came across: I was trying to find
> the method that returns all tables in the database. I correctly guessed it
> was Database#tables, but couldn't find it in the Database rdoc. Since the
> method is only defined by individual adapter-specific subclasses, it doesn't
> show up there.
>
> I suggest adding documentation in the base class for common adapter-defined
> methods. Rdoc's :method: directive is good for this:http://ruby-doc.org/ruby-1.9/classes/RDoc/Parser/Ruby.html

I agree that methods that are defined on multiple common adapters
should be documented in Sequel::Database. For consistency, they
should have actual default definitions that raise NotImplemented.
This would include methods such as tables and indexes.

Jeremy

deepak

unread,
May 4, 2010, 4:38:33 AM5/4/10
to sequel-talk
hi,
i have always liked the apidock site.
http://apidock.com/rails/ActiveResource/Base

the template and search feature is nice, also the user-generated
comments by a user can be a lifesaver.

regards,
deepak

On Apr 16, 2:39 am, pete <p...@peterhiggins.org> wrote:
> On Apr 14, 11:30 am, Jeremy Evans <jeremyeva...@gmail.com> wrote:
>
>
>
> > On Apr 13, 3:39 pm, Shawn <svicalifor...@gmail.com> wrote:
>
> > > Jeremy,
>
> > > You've done a great job maintaining and expanding this library.  At
> > > this point, I think it needs adoption and community more than new
> > > features.  With Rails 3 now supporting ORM choice, Sequel has an
> > > opportunity and a challenge: Rails now allows ORM choice, and
> > > ActiveRecord AREL is claiming Sequel's long-time features as its own.
> > > It's an excellent time to make the case for Sequel by improving its
> > > web presence and online promotion, including:
>
> > > * A new web site to organize all the docs and examples in one place
>
> >http://sequel.rubyforge.org/documentation.htmlprettymuch does this.
> > I'm certainly willing to consider design changes to make it more user
> > friendly, though I'm not sure what they'd be.
>
> > > * More documentation: entry-level and advanced, from intro to
> > > comprehensive
>
> > Introductory documentation is Sequel's weakest area, IMO.  The RDoc
> > documentation is fairly comprehensive, but admittedly terse in a lot
> > of areas.
>
> > Unfortunately, people are not specific when they ask for introductory
> > documentation, and not being a beginner, I'm not sure what the basic
> > stumbling blocks for new users are.  If you could give a rough outline
> > of the documentation you'd like to see, I could probably work on it.
>
> > > * An updated/more attractive logo (these things do influence
> > > perception)
>
> > Not being a graphic designer myself, this isn't something I'm
> > qualified to do.  However, if someone were to provide a better logo, I
> > would not have a problem changing.
>
> > > I'd be happy to help with this, but I may not be able to contribute a
> > > lot until next month.
>
> > I would definitely appreciate the help.
>
> > Thanks,
> > Jeremy
>
> Jeremy,
>
> RailsGuides has a few articles on using ActiveRecord that you could
> potentially use as inspiration for Sequel. Something like this one for
> querying,http://guides.rubyonrails.org/active_record_querying.html,
> and this one for associations,http://guides.rubyonrails.org/association_basics.html,
> probably would have helped me understand Sequel sooner.
>
> Speaking of AR, it seems like a lot of people migrate to Sequel after
> using AR, so a comparison page between AR and Sequel might get people
> up to speed faster. I don't really mean "why you should use Sequel
> instead", but some documentation of how they differ, equivalent Sequel/
> AR idioms, etc.

Jeremy Evans

unread,
May 5, 2010, 7:03:44 PM5/5/10
to sequel-talk
On Apr 21, 12:26 pm, Jeremy Evans <jeremyeva...@gmail.com> wrote:
> On Apr 15, 2:39 pm, pete <p...@peterhiggins.org> wrote:
>
> > RailsGuides has a few articles on using ActiveRecord that you could
> > potentially use as inspiration for Sequel. Something like this one for
> >querying,http://guides.rubyonrails.org/active_record_querying.html,
> > and this one for associations,http://guides.rubyonrails.org/association_basics.html,
> > probably would have helped me understand Sequel sooner.

I've finally committed a Sequel Querying Guide:
http://github.com/jeremyevans/sequel/raw/b3e79b32fec274b069ef8077c8007d4cb9e63865/doc/querying.rdoc

If anyone could take the time to review it, I'd appreciate some
feedback.

Thanks,

Michael Lang

unread,
May 5, 2010, 11:58:06 PM5/5/10
to seque...@googlegroups.com
Jeremy,

This is most excellent.  I learned several new tricks just reading through this guide.  Several nifty little shortcuts were exposed that I was completely unaware of.   Like just providing the column identifier for boolean true results or the get() method to get a column's value straight away. 

Has the tilde prefix (~) gone away in favor of the invert/exclude methods you doc'd?  (didn't see any tips on using tilde).

All in all, you've exposed a lot of useful features that should be in my every day toolbox (and weren't) in an organized and accessible page. This will definitely be one of my primary goto pages.

Regards,

Michael 
--
http://codeconnoisseur.org

Jeremy Evans

unread,
May 6, 2010, 12:16:09 AM5/6/10
to sequel-talk
On May 5, 8:58 pm, Michael Lang <mwl...@cybrains.net> wrote:
> Has the tilde prefix (~) gone away in favor of the invert/exclude methods
> you doc'd?  (didn't see any tips on using tilde).

No, you can still use it, I just didn't think of it while I was
writing. I'll add it to my todo list.

Generally, I use exclude, unless I need to do something like:

A OR NOT B

Because exclude ANDs the conditions, you can't use it, so you have to
do:

filter(:a).or(~:b)

or:

filter(:a | ~:b)

Though for something as simple as that, I'd probably do:

exclude(:b).or(:a)

So I mostly use ~ when I have an existing dataset I want to add an OR
NOT condition to, where I can't reorder the method chain.

Long story short, I use ~, &, and | for complex cases that can't be
done easily using the regular method calls. While it is very helpful
to not have to drop down to SQL and use placeholders, I find regular
method calls more readable than ~, &, and |, so I use regular method
calls where I can. The code is a little longer, but it's also more
understandable.

> All in all, you've exposed a lot of useful features that should be in my
> every day toolbox (and weren't) in an organized and accessible page. This
> will definitely be one of my primary goto pages.

That's good to hear. Thanks for taking the time to read it and give
feedback.

Jeremy Evans

unread,
May 11, 2010, 6:42:11 PM5/11/10
to sequel-talk
On May 5, 4:03 pm, Jeremy Evans <jeremyeva...@gmail.com> wrote:
> I've finally committed a SequelQueryingGuide:http://github.com/jeremyevans/sequel/raw/b3e79b32fec274b069ef8077c800...
>
> If anyone could take the time to review it, I'd appreciate some
> feedback.

I've added a migration guide similar to the ActiveRecord one, which
explains how to use the new migration DSL recently added, as well as a
more in depth description of Sequel's schema modification methods. If
someone could review and give me some feedback, I'd appreciated it:

http://code.jeremyevans.net/sequel-www/rdoc/files/doc/migration_rdoc.html

Expect blog posts soon explaining the migration improvements, as well
as a new blog look from boof (who designed sequel.rubyforge.org).
Reply all
Reply to author
Forward
0 new messages