On Feb 15, 7:42 pm, Will Bryant <[email protected]> wrote:
>
> How about not putting that column (and the meaningless NULL value)
> into the INSERT statement if it is a new record on a column with a
> default value function (as opposed to a default value constant, which
> is the norm)? Would that work?
well, it depends on on the db. with postgresql yes, with mysql the
null is fine. the fact is that it would have to be determined per-
connection adapter. that sounds like a lot of work to me. i know i
cannot provide a patch for every connection adapter myself. you're
advocating maintaining 10 or 20 bits of code which need to be tested
against 10 or 20 dbs who themselves have changing apis. that's not
very pragmatic which a 10 lines patch will handle all cases - IMHO.
>
> If I understand what you're aiming for correctly, I think you may meet
> resistance to getting ar-defaults into Rails core, because
> non-constant default values is a thing that not many people use with
> an ORM layer, and does not fit well into the ORM lifecycle; for
> example, it is expected that when you initialize a new record, the
> attributes on that record should all be fit to display.
you mean outside of after_initialize, after_create, before_save, etc,
etc? afaikt those are all about having dynamic attributes.
> If the
> attribute value isn't determined until the record gets inserted into
> the database, that's a no-go. (Similarly you'd need to reload the
> attributes after insert to find their values after save.)
well - i fail to see how this is in any way different from an
after_save hook. ar has tons is issues that require reloading - with
the object itself and it's associations. anyone that's every writtten
an application with more that a 'posts' and 'comments' table can
attest to this. consider something at simple as 'created_at' and
'updated_at'.
also, your comments are simply not true (wrt 'no-go') with any case
where a db default value exists - you will always have to save and
reload the record to see the default - ar flat out does not handle
this case - it (appropriately) let's the db do it.
> As a
> general rule, I think "we" like doing our model work in our app,
> rather than the DB - it's more of a choice we've made than a "this is
> the only right way to do it in the world" kind of statement, there's
> plenty of room to do it other ways.
ar uses the db to generate ids because they are so important for RI to
function. why should other RI constraints be any different?
it's worth nothing that my request is *precisely* motivated by the
desire to stay in the app. i personally will not even use
'find_by_sql' in any of my code in any circumstance and have avoided
using any sql in my own code for the last 4 or 5 applications. but
recall that doing something as simple as 'find not in(list)' currently
*requires* the use of sql with AR - it is not always possible to avoid
sql.
>
> IMHO, there'll always be people who need to step outside the box
> sometimes, but unfortunately core Rails libraries can't necessarily
> cater to all of them - we'd end up like Microsoft Word where everyone
> only uses 10%... but a different 10% each :).
>
> But if there's something simple that we can do to make life easier for
> them, maybe that's a better bet, whether it's cleaning up internals
> slightly to make it easier to hook in plugins, or maybe if it's a
> small patch making changes like detecting "special" columns and
> leaving them out of inserts (if that works, as above).
hrm. i guess i don't feel like a 'not null default' column is out of
the box in any way. it may be for blogging applications, but anyone
who has been dropped into a data model with 200 tables with hardly
find this paradigm out of the ordinary. please keep in mind that the
current AR is a total FAIL in this case with some dbs - you cannot use
it at *all*. consider explaining that to IT - it's not professional
and makes rails look like a toy.
>
> Personally, I think
> thehttp://drawohara.com/post/78208216/rails-activerecord-defaults-for-ra...
> you posted looks pretty clean already, so I think that should just get
> released as a plugin. We've all got our own list of "10% of Microsoft
> Word" features we need from our own plugins, me included :).
sure - it *was* good. now it does work at all. AR isn't designed to
allow plugins like this to function across versions - they have to get
to deep into messy internals and are therefore fragile. that old code
no longer works as a result and i'm sure my new code will stop working
soon too for the same reasons. this is not fault of AR - it's a
complicated peice of code and i think it's unreasonable for it's
maintainers to support an unchanging internal interface, which is
what's required for plugins acting this level to function across
versions.
this is precisely why i think AR needs to support literal values in
general - then it *is* possible for a plugin to support this use case
simply. it's the lack of literal sql values of any type that needs to
be in core. both dm and sequel currently support sql literals, for
instance in sequel you can say:
dataset.update(:updated_at => :NOW.sql_function)
dataset.update(:updated_at => 'NOW()'.lit)
dataset.update(:updated_at => "DateValue('1/1/2001')".lit)
dataset.update(:updated_at => :DateValue.sql_function('1/1/2001'))
any objection to having sql literal support (all ten lines of it)
should apply equally to find_by_sql, connection.execute,
set_table_name, etc. and yet all of those exists and are heavily
used. to me it just seems idealistic and non-pragmatic.
my 2cts.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" 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/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
