These types of APIs are typically referred to as Fluent Interfaces, so
adopting that nomenclature seems appropriate.
On Mon, Aug 12, 2013 at 4:25 PM, Amiel Martin wrote:
> I like this idea and I would use it.
>
> My only suggestion would be to normally return a new instance of the proxy
> objec
Or all(true)
On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant wrote:
>
> On 28/02/2013, at 11:17 , Jon Leighton wrote:
>
> > #reload will always run the query.
> >
> > If I'm misunderstanding the use case please provide some examples.
>
> Hmm. But you can't run reload on a scope to get an array -
This seems really cool. Is Spring appropriate running on production
servers? For example, on deploy, many different rake tasks may be invoked
(asset compilation, database migrations, etc...) and having something like
this spawned could result in a significant speed-up.
On Sun, Feb 24, 2013 at 7:36
One small thing I'd like to point out is that running migrations serially
is not the same as recreating the database from a schema dump. For example,
the Rails migration `timestamp` directive has flip-flopped in its behavior
(`created_at` was originally nullable, then not nullable, then nullable
ag
Sounds nice.
On Mon, Jul 9, 2012 at 12:23 PM, Kurt Werle wrote:
> dup takes no args
> create and new both take the same args, and create can take a block
>
> It seems to me it would be more consistent (and convenient) if I could do
>
> some_record.dup(attributes_i_want_to_change) do |dup_record|
On Mon, Jun 4, 2012 at 3:32 PM, Ryan Bigg wrote:
> Oh, reading this again it seems I was wrong.
>
> How would it guess the associations?
Indeed
The way that many apps deal with this pain is using shortcut urls like
/issues/5 that simply get the indicated record, look up the parent
records, and t
I find when developers are working on several branches simultaneously
merges tend to conflict on the `ActiveRecord::Schema.define` line in
schema.rb.
My understanding is that schema.rb represents the database schema as it
exists after running *all* the migrations in db/migrate
It seems that the v
Including all the items in an Array and picking the first present one
circumvents any opportunity to use logic short-circuiting to avoid
unnecessary, potentially expensive calculation, not to mention unnecessary
allocation of container objects and the overhead of symbol-to-proc.
+1 for nonblank?
This just feels a little backwards. Enforcement of how many records are in
the db is not the responsibility of the finder. Uniqueness should be
enforced in the database and in the parts of the application that insert and
update data.
I concede it would be useful to have a more-flexible form of
A
Perhaps the name "default_scope" is a little misleading, implying that this
scope is the default unless you pick something different. Another name like
base_scope, parent_scope, or master_scope could address the mismatch between
expected and actual functionality.
On Sun, Jul 26, 2009 at 2:20 PM,
Instead of extracting a specific piece of a named_scope's proxy
options, I would probably elect to use a more flexible,
object-oriented solution using inheritance.
http://gist.github.com/71604
On Fri, Feb 27, 2009 at 9:37 AM, Luke Redpath wrote:
>
> In my current project, I have an association
Hash doesn't preserve order, which is critical when declaring indices.
On Mon, Feb 2, 2009 at 4:57 PM, Carlos Henrique Palhares
wrote:
>
> Fine! but I would replace this:
>
> add_index(:accounts, [:name, :surname], :name => 'by_name_surname',
> :limit => {:name => 10, :surname => 20})
>
> by:
>
I'm sure you read Frederick's response about the counter_cache being
readonly.
The way to properly populate these during a migration is to redeclare the
Learner class as an inner-class of the Migration itself, specifying only
minimal functionality.
class AddCounterCacheToLearners < ActiveRecord::M
There are also faster YAML dumpers out there. A recent Portland code sprint
produced ZAML, a work-in-progress that offers (if I recall correctly)
something like a 14x speed boost over vanilla YAML.dump
http://github.com/hallettj/zaml/tree/master/zaml.rb
YAML's slowness has been a pain point, but
Reading the database configuration in for use in the db:console will
now require loading the entire framework! Sweet!
On Thu, Jun 12, 2008 at 12:38 PM, DHH <[EMAIL PROTECTED]> wrote:
>
>> Why was yaml used in the first place?
>
> Because I thought dammit, we gotta use YAML for something -- aka n
There's also the issue of models referenced from within migrations
where you might want to explicitly specify a module hierarchy that
does not match the model's actual namespace.
Perhaps we can include a method that allows you explicitly set the sti
class name?
class SomeMigration < ActiveRecord
Also, if for whatever reason the request was retryed (by a proxy
perhaps) even a single user's actions could result in an unknown final
toggle state.
+1 for removal
On Feb 16, 2008 1:05 PM, Jarkko Laine <[EMAIL PROTECTED]> wrote:
> On 16.2.2008, at 20.43, Tammer Saleh wrote:
> > The correct solu
Currently image_tag throws an error generating the alt attribute for
images whose basename contains only periods.
Suggest simply casting possible nil to_s.
-options[:alt] ||= File.basename(options[:src],
'.*').split('.').first.capitalize
+options[:alt] ||= File.basename(options[:
18 matches
Mail list logo