Jim Cain wrote:> Adding standard methods to AR''s database adapter model to support
such
> things shouldn''t be too difficult. For example, to populate
drop-downs
> for foreign keys, it could look for an appropriate method in the
> adapter. If the database supports discovering fkeys, then the method
> exists; if not, it doesn''t, or returns nil or something
appropriate.
Indeed. Discovering metadata is not a big deal, but with many databases
to support it''s (unfortunately) prohibitive to develop and test.
Active
Record could really use a smoke-test box running every supported db.
Regarding the preceding thread''s speculation whether MySQL can tell you
whether a column is nullable: try ''desc tablename'' in your
client.
> Another thing that should change is sequence generation. Just because
> MySQL has a datatype that supports this directly in a table
doesn''t
> mean all databases do. There should be a way to use a table-specific
> function to generate a unique ID, such as sequences in Oracle.
PostgreSQL does it by defaulting the primary key to nextval(sequence).
Many can (and do, in Active Record adapters) emulate this behavior, but
there''s no sense cramming it down their throats.
To make things easy on the developer *and* the db, we could provide an
id generation strategy by passing a block to the primary key declaration:
# By default, foo_id set to a serial int by the db adapter.
class Foo < ActiveRecord::Base
# foo_id set to UUID.new
primary_key { UUID.new }
# foo_pk set to UUID.new
primary_key(''foo_pk'') { UUID.new }
# FOOID set to nextval("schema.some_global_seq")
primary_key(''FOOID'') {
''nextval("schema.some_global_seq")'' }
end
> If there is real value in these changes, I wouldn''t mind
contributing
> some of them myself.
There certainly is! Thanks for digging in. Further discussion is
probably better-suited for the Rails list; I''ve cross-posted.
jeremy