On Sep 11, 3:53 pm, Gavin Kistner <[EMAIL PROTECTED]> wrote:
> On Sep 11, 2008, at 9:24 AM, Jeremy Evans wrote:
> > On Sep 10, 8:11 pm, Phrogz <[EMAIL PROTECTED]> wrote:
> >> irb(main):004:0> t1.count
> >> NoMethodError: undefined method `count' for #<Tag
> >> @values={:count=>"1", :"`name`"=>"amx"}>
> >> from (irb):4
>
> > This is expected as count is not a column of the tags table, so no
> > instance method is created for it, and Sequel no longer implements
> > Model#method_missing.
>
> I understand that it may be expected by you, though it was not by me.
> (I'm not arguing anything here, simply sharing my impressions as a
> first-time user.) As a consumer of the data, I expect a consistent way
> to access columns of data selected from the database. When I use joins
> or aggregate functions to expand the available columns beyond what the
> 'main' table has in its schema, I no longer think of rows in the
> resulting tuple-set as being part of the 'main' table. As such, and as
> a consumer of data, I (personally) don't see how it matters that I
> happen to have started with the tags table or Tag model.
Arguably, group_and_count should return plain hashes and not model
objects, since they don't really represent a particular object, but an
aggregation of a collection of objects. It's possible I'll make that
change in 2.6.
> I'm not necessarily suggesting that you ought to use method_missing or
> custom modules mixed-in on the fly. Although I find method-invocation
> notation nicer than hash notation, I'm only suggesting that access to
> named columns in a row should be the same irrespective of whether I'm
> iterating a dataset or array, and irrespective of whether the columns
> are in the DB schema or not.
If you want a consistent way, use Model#[], as that will work both for
columns and computed values such as count.
> > At one point, there was an option of using arrays that had been
> > modified to look like hashes, but support for that was removed quite a
> > while ago.
>
> Since I'm just joining the community and genuinely interested, could
> you point me to a posting (if it exists) or describe the rationale for
> this?
It cluttered the code and it wasn't fully debugged. Since it wasn't
the default, almost nobody used it. I can't recall one complaint
about the removal since we removed it, so my guess is no one used it.
> >> That the name of the existing column must be specified using symbol-
> >> literal notation with backquotes is what pushed me over the edge to
> >> getting online and reporting this.
>
> > This is also a bug in SQLite. You get the same results from the
> > sqlite3 command line tool:
>
> FWIW, at least some in the SQLite community do not consider it a bug.
> Here's the response I got when complaining about this:
>
> > In the absence of an AS clause, SQLite makes no promises about column
> > names. If you want a specific column name, use an AS clause on that
> > column to specify the name. Otherwise, you get what you get and what
> > you get might change from one point release to the next. (That said,
> > people tend to scream furiously when the column naming rules changes,
> > so we do try to avoid changing them without a very good reason.)
>
> -http://article.gmane.org/gmane.comp.db.sqlite.general/41090
SQLite may not consider it a bug, but I do, as no sane database should
operate that way. That said, I'd be willing to consider a patch for
the SQLite adapter that used AS for regular columns.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
