Jeremy, thank you for your quick and in-depth reply. A few responses
inline:
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.
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.
> 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?
>> That the value of count comes back as a string is really annoying,
>> almost on the verge of being a bug.
>
> That's a problem with SQLite (possibly ruby-sqlite3), not with Sequel:
Confirmed that this is certainly a problem with ruby-sqlite3. (Not
sure yet if it's SQLite not passing the appropriate metadata along.
Thanks!
>> 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
I've confirmed that (pursuant to the suggestion above) you could
likely work around this problem in Sequel by using an AS clause:
sqlite> .headers on
sqlite> create table bar (`select` text);
sqlite> insert into bar values ('a');
sqlite> select `select` from bar;
select
a
sqlite> select `select`, count(`select`) from bar;
`select`|count(`select`)
a|1
sqlite> select `select` as `select`, count(`select`) as hits from
bar;
select|hits
a|1
I have no guesses or tests, however, on how throwing an AS clause on
every column might impact performance. As a user who loves to use
SQLite when possible, though, I know that I would certainly appreciate
it.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
