4 ms·

In the absence of instructions telling it to do something different, AR relies on the convention that instances of a class Foo are stored in a table called "foo

In the absence of instructions telling it to do something different, AR relies on the convention that instances of a class Foo are stored in a table called "foos", regardless of what database system you're using. That cuts down on the amount of configuration you have to do, and you wouldn't normally override it unless you were applying AR to a preexisting schema. Edit: removing speculation

saurik 12y ago
OK, and I then imagine the idea is that the kind of person using ActiveRecord doesn't "design their database with the idea of multiple potential consumers, only one of which might be ActiveRecord"? Fair enough. Regardless, the primary question that my post was leading up to stands: a table with the name "foos" will still have what is effectively an implicit column with the name "foos" that is a record value of type "foos".
- icambron 12y ago
  People pick their tools per-project, so I would put it as "if you need to build a database with multiple consumers, AR will be a less valuable choice for any of them, and you are thus much less likely to use it for that project". Right tool, right job, etc. On your primary question, since I've now played with "select foos from foos" on my PG database: I doubt it. When you do a query like Foo.where(foos: 'value').to_a or Foo.find_by_foos('value'), what you're basically doing is a "select foos.* from foos where foos='value'". If foos doesn't actually exist as an explicit column, that doesn't actually work: PG::UndefinedColumn: ERROR: column foos.foos does not exist So it's not like people have been writing queries like that expecting that the implicit column will do something (which I'm not sure would make sense anyway). Unless I'm misunderstanding something, it remains the case that you'd have to have explicitly created a column with the same name as your table to trigger this bug with otherwise working code. Edit: Of course, maybe there are more ways to trigger this bug than the ones provided in the email, and maybe they include queries where you might be relying on an implicit column for something else, such as selecting foos from foos. I'm just saying the cases listed in the email don't seem to be affected by the implicit column.
  - saurik 12y ago
    Did you mean "foos.foos = 'value'"? I do not get an error on the column not existing with "where foos = 'value'" (which is the query you wrote). However, it does turn out I'm wrong on a key aspect: PostgreSQL refuses to convert untyped-text to a record without a cast "ERROR: input of anonymous composite types is not implemented" (which would make this require at least a tuple to have been passed into the query to begin with, which seems extremely unlikely, and likely require the cast, which wouldn't happen).
    - icambron 12y ago
      Sorry, yes, I meant "foos.foos='value'", which AR writes because the code generating it doesn't pay attention to what joins you've attached (or in this case, haven't) and what ambiguities that might create, so it does the safe thing. I also noticed the error you mentioned when playing with it, but didn't understand it well enough to be confident there was no way to force that cast.

saurik 12y ago

OK, and I then imagine the idea is that the kind of person using ActiveRecord doesn't "design their database with the idea of multiple potential consumers, only one of which might be ActiveRecord"? Fair enough. Regardless, the primary question that my post was leading up to stands: a table with the name "foos" will still have what is effectively an implicit column with the name "foos" that is a record value of type "foos".

icambron 12y ago
People pick their tools per-project, so I would put it as "if you need to build a database with multiple consumers, AR will be a less valuable choice for any of them, and you are thus much less likely to use it for that project". Right tool, right job, etc. On your primary question, since I've now played with "select foos from foos" on my PG database: I doubt it. When you do a query like Foo.where(foos: 'value').to_a or Foo.find_by_foos('value'), what you're basically doing is a "select foos.* from foos where foos='value'". If foos doesn't actually exist as an explicit column, that doesn't actually work: PG::UndefinedColumn: ERROR: column foos.foos does not exist So it's not like people have been writing queries like that expecting that the implicit column will do something (which I'm not sure would make sense anyway). Unless I'm misunderstanding something, it remains the case that you'd have to have explicitly created a column with the same name as your table to trigger this bug with otherwise working code. Edit: Of course, maybe there are more ways to trigger this bug than the ones provided in the email, and maybe they include queries where you might be relying on an implicit column for something else, such as selecting foos from foos. I'm just saying the cases listed in the email don't seem to be affected by the implicit column.
- saurik 12y ago
  Did you mean "foos.foos = 'value'"? I do not get an error on the column not existing with "where foos = 'value'" (which is the query you wrote). However, it does turn out I'm wrong on a key aspect: PostgreSQL refuses to convert untyped-text to a record without a cast "ERROR: input of anonymous composite types is not implemented" (which would make this require at least a tuple to have been passed into the query to begin with, which seems extremely unlikely, and likely require the cast, which wouldn't happen).
  - icambron 12y ago
    Sorry, yes, I meant "foos.foos='value'", which AR writes because the code generating it doesn't pay attention to what joins you've attached (or in this case, haven't) and what ambiguities that might create, so it does the safe thing. I also noticed the error you mentioned when playing with it, but didn't understand it well enough to be confident there was no way to force that cast.