We can't accept a feature without know what are the
impacts in the codebase.
In the application I maintain I don't need code to understand the
impact of some feature. I don’t understand why that would be
different for Rails maintainers.
This is valid for everyone, either the core members.
I can say that I want this feature and accept it, but
nothing stops the core members to revert it. And don’t expect
me to defend your feature, since you should be the interested.
My perception is that although this list is called rails-core it
seems core members don’t actually read it. Otherwise it would be
easy to achieve a consensus about approving this feature or not
before implementing it.
It seems to me that you're suggesting that Rails development is much
more like an anarchy. Listening to Aaron in some podcasts also seems
to indicate that this is the case as well. This is how I’m
understanding development happen on Rails core:
- a core member wants a feature
- he writes the change, commit it and push it
- another core member don't like the change and revert the commit
- some other core member liked the change and revert the commit that
has been reverted
How is that sane? In what point prior discussion became invaluable?
This is not how I manage my teams/softwares and I’m pretty sure this
is not how most projects out there work.
Would be more waste of time if we accept it now and, when
you come up with the code, we rejected it because it add more
complexity in the framework that we want.
You should be able to understand the impact in complexity that such
a simple feature like that would have in the code base beforehand.
If it happens that you don’t like my change, I’d expect you to show
me how you think such feature should be implemented instead. But it
wouldn’t be rejected. At some point the implementation would conform
to what the core-team expect it to look like.
Also, what is the difference of writing 10 huge emails
and get the feature reject?
Getting the feature rejected is not the issue. Spending time on
developing the feature that got rejected is. I don’t consider my
e-mails huge (they are not small) but I see that for today’s
standards where people got used to Twitter (I can’t use it) my
messages may seem huge. But I don’t spend much time writing messages
as I would spend to start contributing to any big open-source code.
See, last time I contributed to Rails was several years ago, much
has changed since then and I’d need to read tons of instructions and
code before I started to contribute again. Additionally, AR is
inside Rails repository. That means that I can’t just point to AR
master in my Gemfile for instance, but this is a separate issue, let
me get back to the subject.
In the end I just don't mind discussing features, but I do mind
writing code that won’t ever see the light of the day just because
people can’t discuss them up-front. This is similar to the
Refinements discussion in the Ruby-core list. It started with code,
that code has been merged to trunk even before the discussion
started. I’m pretty sure Charles Nutter was able to tell the
performance impacts and had more insights about that feature just
looking at the proposed feature description without starting coding
it. If this discussion had started before the feature being
implemented the first implementation would probably be much more
aligned to the final specs and with less effort.
I think is the same. With working code you have more
chances. And, as I said in my last email, either if we don’t
accept, you will have working code that solves your problem.
No, I won't. First, I don't have a problem. I use PG and I have no
plans to support other DB vendor. But it crossed my mind the idea
that maybe some open-source software could benefit from a common API
to add support for deferrable unique constraints because some very
common use cases (ordered tree/list) would require that and just
asked here if there was such an interest in that feature.
But if I were to support that in some OSS project and I knew
beforehand that this feature isn’t going to be accepted in AR I
wouldn’t use all code that I wrote to make a patch to Rails. I would
rather use a much simpler approach:
module ARExtensions
def add_deferrable_unique_index(table_name, columns, options={})
(add_index table_name, columns, options.merge(unique: true);
return) unless db_supports_deferrable_constraint?
name = options[:name] || ['idx', table_name, columns,
‘unique’].flatten.join(‘_’)
execute "alter table #{table_name} add constraint #{name}
unique (#{columns.join ', '}) deferrable"
end
private
def db_supports_deferrable_constraint?
# TODO: code to detect database and version here - would
return true for PG and false for MySQL
end
end
Then just include that module in your migration classes when you
need add_deferrable_unique_index. Much simpler to write than writing
a patch to AR with docs and tests.
If you don't want to scratch your itch and provide a
patch, I’m sorry, but don’t expect we to accept.
Ok, I get the message, just don't expect me to contribute to Rails
if I have to submit the code before discussing it.
And, just for record, I don’t like Cucumber 
Me neither :) But I had to try to convince you, maybe you were a
Cucumber fan, who knows?
: 