+1 for the the original behavior where chained clauses are ANDed
(POLS).
On Feb 16, 8:35 am, Brian Morearty wrote:
> > Sound arguments. I didn't implement collapse_wheres, just in case a
> > witch hunt starts. I was just the first person awake this morning to
> > pose the answer. :)
>
> Understoo
I ran into some issues with the response content type for action-
cached pages. After digging through the code and reading up on some
of the lighthouse tickets, I'm proposing a reset of the thinking for
how cached content is matched up to requests. The biggest problem
with the current implementat
Jarl,
I've been listening in on this conversation and it brings to mind a
discussion a while back on the use of presenters and reverse
presenters. Since the dawn of time, ActiveRecord (and perhaps even
ActiveModel) has been tightly wedded to the concept of unreliable
human input (= HTML forms). G
The thought of parsing the stylesheets to replace url references seems
pretty clunky. Could something like Sass address this problem more
cleanly?
On Jan 20, 6:29 pm, Corin wrote:
> Hi all,
>
> when using stylesheets caching in rails, one might get problems if the
> stylesheets contain relative
I spent an entirely inappropriate amount of time digging into this
issue...
Here are some observations:
The #microseconds method LOOKS clumsy, but it's actually quite
optimized. Turns out the the sec_fraction component is a Rational
less than one. So converting as quickly as possible to som
I gave up on that kind of resolution when I found that MySQL doesn't
support it! I'll try to test the patch though.
-Chris
On Jan 14, 10:20 am, Jacob Lauemøller
wrote:
> Hi all,
>
> The microsecond handling in
> ActiveRecord::ConnectionAdapters::Column#fast_string_to_time and
> ActiveRecord::
Double bonus for this enhancement -thanks Stephen. I see that you
have also made the "name" attribute optional -fantastic. Now one can
implicitly apply a label to the enclosed input without having to worry
about id matching with the 'for' attribute:
label_tag nil, "Your Name" do
text_field_tag
Josh nailed it. This issue of empty strings coming back from forms
has been around for eons (in Rails' hyperspeed timeframe). Firing up
the wayback machine, we see this:
http://dev.rubyonrails.org/ticket/5694
BTW, here's my take on a solution using a before filter to recursively
coerce empty
This commit (f5f7c40f3aedf88b2aef4e83602a4f41ffa5d0ab) introduces a
new limitation for ActiveRecord::Base instances that has (to my
knowledge) never been discussed.
Briefly: an error on an attribute cannot be set as the result of an
exception computing the value of the attribute.
For example:
d
Bump. Worth a look as this is a data corruption situation...
On Nov 3, 9:26 pm, Matt Jones wrote:
> https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3086
>
> Just what the subject says - on 2-3-stable, destroying an object with
> a has_many association using :primary_key an
Done. I've created the ticket and enclosed a patch here:
https://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/105-activesupportorderedhashreplace-results-in-corrupt-keys
Turns out the problem was more fundamental than just
OrderedHash#slice! -it's actually a problem in OrderedHash
I have a method that removes some errors from the
ActiveRecord::Base#errors object. After updating my app to 2.3.4, I
find that the removal process is broken. Witness:
h = {:a => 1, :b => 2}
oh = ActiveSupport::OrderedHash[:a, 1, :b, 2]
h.slice!(:a)
h.keys => [:a] GOOD
oh.slice!(:a);oh.key
Henrik,
I don't think Rails' principal of least surprise was meant necessarily
to extend to your end-users' experience. It applies to YOUR
experience. Then, in turn, you are responsible for making your users'
experience unsurprising (amongst many other positive adjectives).
The first developmen
I know aggregations are not the most exciting part of Rails these
days, but can someone please look at this ticket/post?
-Chris
On Jun 3, 8:56 am, Chris Cruft wrote:
> For those of you that are familiar with composed_of/aggregations, I've
> created a patch to address a small
For those of you that are familiar with composed_of/aggregations, I've
created a patch to address a small bug in the writer's behavior when
the converter returns nil.
Currently the writer first checks for nil assignment, and only then
does it set the mapped attributes to nil. If the assigned val
"...aren't we supposed to be acolytes of Agile, and iterative
improvements?"
Yes. And I didn't mean to imply that a total refactoring of
associations was an absolute condition of "success" or that a "just
refactorings" effort does not have merit.
Roughly, I'm in complete agreement with Adam's or
Having just spent a lot of time wading through the HMT and HOT code,
I'll agree that there is a lot of room for improvement w.r.t.
clarity. And if there is a general agreement that a refactoring is
needed then the longer we wait the tougher the job will be. I would
encourage Adam's effort.
Howe
es (those that take
> parameters) are not supported. I could not think of a clean syntax to
> deal with the
> parameters and I wasn't (yet) prepared to support a proc/lambda as the
> param. As a side note, the chicken-and-egg problem of specifying
> association by having ea
Get this man hooked up to the wagon! It's great to see this level of
thought going into Rails I18n, and equally wonderful to know that his
efforts could positively impact the framework.
On Apr 21, 5:08 am, geekQ wrote:
> We have been working on a Rails application for a big company, that
> will
lean syntax to
deal with the
parameters and I wasn't (yet) prepared to support a proc/lambda as the
param. As a side note, the chicken-and-egg problem of specifying
association by having each end refer to the other frustrates clean
syntax...
-Chris
On Mar 31, 12:24 pm, Chris Cruft wrote:
>
The named_scope macro introduces a concise syntax for a complex set of
[:order, :conditions, :joins, :include, :offset, :limit, :readonly]
options for a model class. The options for the association macros use
most of those SAME OPTIONS. My first suggestion is that association
macros accept a :sc
This thread risks getting stale, which would be a shame because the
need is obvious and we've got a couple of good proposals on the
table. I took the time to more carefully review Ryan's proposed
syntax, and I'm loving it. I will try to work up an implementation
but I'll probably need someone el
Not a patch, but last I checked assert_select_email didn't work -
undefined method in ActionMailer::TestCase subclasses.
On Mar 9, 8:03 am, Pratik wrote:
> Hey all,
>
> As 2.3 RC2 is out, the plan is to have the 2.3 final release out as
> early as possible. So we'd like to make the last call fo
I'm liking all of this goodness. I suspect that the syntax of Ryan's
solution will be more appealing to most.
On Feb 27, 1:45 pm, Ryan Bates wrote:
> -1 on inheritance solution. It is creative, but I imagine that can get
> messy very quickly if you have multiple attributes you're trying to do
>
diff. It's quite short. All
> it does it in the instance of adding multiple items to a many to many
> relationship at once, it converts a _specific_ set... ["1,2,3,4"] to
> [1,2,3,4]. It wouldn't do anything to ["A,B,C,D"] or anything else you
> could dream
It seems like this conversion would be better handled in the
controller or model.
Using anything other than integer primary keys also becomes riskier.
So far Rails has done a pretty good job of permitting non-integer
keys. I would hate to see that fall by the wayside.
-1
On Feb 20, 7:39 pm, i
You mean like the 'id' column?
On Feb 15, 9:42 pm, Will Bryant wrote:
> 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
Matt,
I've seen this behavior and wondered if that behavior was legit. But
it didn't seem to have any adverse effect and so I moved on to other
things. Admittedly, I didn't test the behavior of all mailers in the
wild though...
Can somebody definitively point to the SMTP spec for addressing and
+1
I pushed for this same refactoring a couple of months ago to fix some
issues with assignment to the proxies. It's overdue.
-Chris
On Dec 27, 9:44 am, Adam wrote:
> I see what these two classes have in common, but I don't like that
> they share implementation via an inheritance relationship
Completely agree with Frederick's initiative to clean this up.
Letting the form builder control the error markup is appropriate. A
default configuration that renders a shared partial for errors might
be a good approach -that would allow customization of layout without
customization of code.
Oth
I know of at least two of my apps that will break. But I also agree
with the sentiment of
dealing with a slightly higher abstraction than just strings when
working with the filesystem.
So I'm willing to pay the (small) price and I thank you for bringing
it to my attention!
On Dec 7, 5:10 pm, "Mi
associations.
On Dec 5, 11:14 am, Chris Cruft <[EMAIL PROTECTED]> wrote:
> I don't have a lot to offer to this subject except to say that in my
> experience of building declarative bidirectional relationships in
> Javascript (to proxy AR records!) I found that "promoting" the
I don't have a lot to offer to this subject except to say that in my
experience of building declarative bidirectional relationships in
Javascript (to proxy AR records!) I found that "promoting" the
associations to a full-blown model was quite clean. If done directly
in AR, I could imagine somethi
Koz (or others),
Has this issue has been addressed, and if so, in which commit?
-Chris
On Nov 7, 3:07 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
> > Solution: I moved the `require_frameworks`call to the start of
> > `Initializer#process`. Of course, `silence_warnings` is not defined by th
I've seen this behavior as well: my initializers were not being run
during a gem install, but application.rb was being required. Inside
initializer.rb, the "gems_dependencies_loaded" test was not being met
and so the "load_application_initializers" method had no effect.
In my case, the initiali
Makes all the sense in the world.
On Oct 28, 11:03 am, "Carlos Henrique Palhares" <[EMAIL PROTECTED]>
wrote:
> http://rails.lighthouseapp.com/projects/8994/tickets/1285-patch-reduc...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
Shouldn't asset tag helpers (like image_tag) be able to return
absolute paths without asset_host being set?
Both rely on compute_public_path to generate the path. Depending on
the value of its "include_host" argument (always true when called from
the image helpers), compute_public_path tries to
the source data comes from and how it is stored.
I've got to mull this one over now...
-Chris
On Aug 28, 9:23 am, Manfred Stienstra <[EMAIL PROTECTED]> wrote:
> On Aug 28, 2:03 pm, Chris Cruft <[EMAIL PROTECTED]> wrote:
>
> > I looked at the proposed attribute-decora
I looked at the proposed attribute-decorator plugin a bit and found it
pretty simple. But (assuming I understood it) the simplicity comes
with a noticeable penalty for the use case where you want to use a
standard class for the decorator that does not include a parse factory
method: another wrapp
Rob,
I like your patch: it solves problems I have had and the aesthetics of
a proc feel right. But the duplication between the constructor code
and the converter code is not DRY. Why not just lump them together
into :constructor? By providing the option to use a proc, you've
already addressed t
further to coerce booleans using external logic. It's the use of
external logic that I characterized as "guessing."
-Chris
On Aug 20, 6:47 pm, "Damian Janowski" <[EMAIL PROTECTED]>
wrote:
> On Wed, Aug 20, 2008 at 12:34 PM, Chris Cruft <[EMAIL PROTECTED]> wrote
n. It's all downhill from here...
Of course it's worth considering combining the Reverse Presenter and
the classic Presenter into one class. That might help with building
some enthusiasm for the idea and it would probably reduce the amount
of modeling required.
On Aug 19, 12:23 pm
The scenario that you mention is a classic one of empty strings being
returned from forms. And the problem is
bigger than just booleans. It also applies to strings, numbers and
lists.
In the scenario Josh mentions, a boolean field should have the empty
string or a blank string coerced to false
Last time I checked (OK, several months ago), every migration file IS
loaded for any migration..
On Jul 11, 8:46 pm, "Nik Wakelin" <[EMAIL PROTECTED]> wrote:
> (I haven't looked at the code; would this require loading every
> migration every time you want to migrate?).
>
--~--~-~--~~
Yes, we did. You might also say that I badgered you about Full-circle
REST...
On Jul 10, 8:02 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote:
...
> > "Full Circle REST" is where it's at.
>
> Definitely, and I think we've discussed this previously on #rails-contrib?
>
...
--~--~-~--~--
Have a look at Resources Controller (RC) plugin, which is a pretty
mature and functional set of functionality for getting the relevant
resources for a controller. RC is strong -I gave up my own solution
to adopt RC (and contribute a bit). Ian White, the author, has really
kept it going.
http://
Any progress on the patch to fix the integer key assumption in the
same code?
-Chris
On Apr 25, 3:31 am, Frederick Cheung <[EMAIL PROTECTED]>
wrote:
> I tidied up some association preload stuff where it wasn't quoting
> table names if anyone wants to take a
> look:http://rails.lighthouseapp.c
Antonio,
I agree that doing something like "edit_post_asset_path(@event,
@movie) is nice. But, again, you don't need to put syntax on routes
to achieve nearly the same effect. As one example, consider the
ResourcesController (RC) plugin which provides helpers like...
edit_resource_path
The ide
Wildchild,
Your patch takes an approach that differs from the one taken by the
ResourcesController plugin. I like the RESULT of your patch (:*_type
key in the params) but, as shown by the RC plugin, I'm not sure the
specification with :polymorphic => is required or wise. Right
now, there is a l
h my patch (failing tests included) posted on this ticket:
http://dev.rubyonrails.org/ticket/11040
Please take a look and consider supporting this patch.
...and we thank you for your support.
-Chris Cruft
--~--~-~--~~~---~--~~
You received this message because
Thanks Michael. I did just that and Ben Scofield pointed me in the
right direction.
Can I get a +1?
-Chris
On Jan 24, 10:58 pm, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> > But I am having a tough time writing a failing test. It seems as
> > though TestRequest does not implement the get
There is a bug in the AbstractRequest getter/setter combo for the
format. It was introduced in changeset 7479 a couple of months ago.
It has escaped detection so far because the "respond_to |format|"
circumvents it. The bug is trivial to understand and fix.
Understanding: Assuming the request
My hero!
On Jan 21, 9:19 am, "Mislav Marohnić" <[EMAIL PROTECTED]>
wrote:
> I've already fixed it, just need to make unit tests and finish the
> documentation. Then I'll submit it in one big patch.
>
> 2008/1/21 Chris Cruft <[EMAIL PROTECTED]>:
>
&g
I'm frequently in need of generating a formatted polymorphic url.
Currently, it's done ugly because the formatted_polymorphic_url code
is broken (see ticket 8782 and Mislav's #2 above). I would like to
see that helper working-but if the job can be done with something
simpler, I'm all for it. Tre
Mislav,
Can you suggest how to do the exact same thing with formatted URLs?
Using adish's example, something using a helper like
edit_formatted_polymorphic_path(record, :xml)
This seems logical, but is busted in Edge (see
http://dev.rubyonrails.org/ticket/8782).
-Chris
On Jan 20, 11:53 am,
This seems so obvious that I gotta believe its somewhere in the code
already.
If it is not, a definite +1 for the idea and I will try to test your
code.
On Jan 13, 1:42 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I submitted a patch a couple of days ago that makes it possibl
I've tried to adopt DHH's approach of using migrations just as a
change agent and relying on the schema dumper to reveal the state.
What I've found lacking in this approach is that the schema dumper
shows the current schema state AS IS, not AS INTENDED. I'm not
perfect in my practices, and perhap
FWIW, the Globalize plugin uses CSV files for it's (substantial)
fixtures. It is much easier to read and scan 3000 columnar fixtures
than the equivalent YAML encoding.
For small volumes, I have no need for anything but YAML. For large
volumes, CSV is nice.
On Dec 2, 8:36 pm, DHH <[EMAIL PROT
"...migrations are transient artifacts that only serve the purpose of
moving everyone on a schema version A to schema version B."
David,
Koz expressed almost exactly this same sentiment yesterday in another
thread (http://groups.google.com/group/rubyonrails-core/browse_frm/
thread/d871469cb2a6589
I'm not sure I exactly follow Robert's use cases, but I sympathize
with the frustration with schema.rb versus migrations. Check out this
thread for a similar discussion:
http://groups.google.com/group/rubyonrails-core/t/d871469cb2a6589a?hl=en
The highly-specific use cases for Robert's patch wil
>>"You run your migrations against your development database, it's hardly as
>>bad as you're implying :)."
True, but... In development, you run the new migrations -you don't
typically tear down the DB and run all of them from the start.
Consequently, older migrations become stale and broken (
Josh's rake task looks like it provides a nice ability to load data
via Rake. But there is an inconsistent message being sent by Rails:
Use Migrations. Use Migrations. Use Migrations.
Except for testing, where we'll use a limited, one-off method (schema
dumper) ensuring that you'll never know
I'll try to review it today.
In any case, it seems like a bug that will irreversibly corrupt your
data. This ticket should be getting serious attention for that reason
alone.
-Chris
On Nov 19, 1:00 am, Tim Lucas <[EMAIL PROTECTED]> wrote:
> Not sure what Jamis is up to, but just in case this f
Michael,
Please see me earlier comment and see ticket 8389 -that's the patch
for a task to support migration-based building of the test database.
-Chris
On Nov 14, 12:29 am, "Michael Koziarski" <[EMAIL PROTECTED]>
wrote:
> > 1 ) What, then, is the preferred mechanism for "seed" data in the
> >
Stephen,
Your questions are a mirror of mine. I am surprised that the emphasis
placed on migrations for building the development and production
databases does not extend to the test database.
There is a rake task proposed on ticket 8389 (http://
dev.rubyonrails.org/ticket/8389) that addresses th
Greg,
Considering the shortcomings in the :ruby schema builder, I'm
surprised that anyone with legacy issues would consider it all:
deviations in primary key structure or name, foreign key constraints,
table types -you name it and the :ruby schema builder can't handle
it. I'm OK with that because
Thanks to those of you that have tested the patch -but I still need
one more tester!
Someone. Please.
On Oct 22, 8:47 am, Chris Cruft <[EMAIL PROTECTED]> wrote:
> I would appreciate it if you could verify this AR patch on ticket
> 9843. In a nutshell, it corrects the beh
I would appreciate it if you could verify this AR patch on ticket
9843. In a nutshell, it corrects the behavior of the composed_of
aggregation in the presence of nil values. This patch, in various
forms, has been submitted by THREE different authors. This time I put
a failing test case in place
It probably would have helped if I had mentioned the new ticket: It
is ticket #9843
http://dev.rubyonrails.org/ticket/9843
-Chris
On Oct 12, 10:05 am, Chris Cruft <[EMAIL PROTECTED]> wrote:
> Looking for love for my patch correcting behavior of composed_of with
> allow_nil =&
Looking for love for my patch correcting behavior of composed_of with
allow_nil => true. This patch, in various forms from various authors,
has been around for over a year. It has never been accepted into core
due to a lack of tests. Well, I've now added the failing tests and
the patch against
Julian has noted disatisfaction with string keys, but I suspect he
didn't use a dummy language...
I'm a big believer that the "dummy language" approach is very
effective. While the concept's name leaves a bit of a sour taste in
your mouth ('dummy'), the concept provides a great ability to
segreg
Some people use the concept of resource nesting or "belongs to" to
manage security, but it is pretty one-dimensional. More robust
security systems (role-based access control, for example) have a much
richer concept of authorization than could possibly be expressed in a
request string. I love nes
I recall hearing the Holy Beasts of Doom argument for overriding new -
but not for initialize. I've been using something like Piers'
approach, which has always worked for me:
def initialize(attrs = {}, &block)
super attrs.reverse_merge(default_attributes_hash), &block
more_initialization_dep
tem, I'd just like a way to
> load the fixtures like they are currently loaded but do it once
> and only once for all tests.
>
> btw. Nested transactions would not necessarily be required for a mixed
> system, but you would have to reload the per-test fixtures after each
> transacti
Tarmo's proposal of having two classes of fixtures (pre-loaded before
all tests, and per-test fixtures) seems very smart. It would also
ease the transition from the current per-test approach.
For performance reasons, wouldn't such an approach require nested
transactions? Not that nested transac
Josh,
I grok what Daniel is trying to say, but I can't tell if you do or
not. Perhaps this will help.
/mother/273753/child/234
/father/342986/child/234
/child/234
In all of those URLs it is very clear which single resource we are
referencing: Child 234. But the URLs give very different context
Josh Writes:
>"/companies/1/people/1" == BAD
>"/people/1" == GOOD
>
>I have no problem with nested collections.
>
>"/companies/1/people"
>
>You shouldn't need to be scoping person #1 if its the unique id.
But isn't that the rub? Who says the ids must be unique? True, Rails
support for composit
I've run into problems trying to anticipate the aliased table name as
well. I think Rails should have a more consistent way to refer to
aliased table names. Perhaps a parameter to the association
definition?
class Employee < AR::Base
...
has_many :subordinates, :class_name => 'Employee', :s
I've wrestled with the same problem. I first render one of several
templates to a string, then include the string within a rendered
template. And my testing breaks (or at least is counter-intuitive) as
well.
It certainly doesn't seem right that rendering to a string dominates
(assert_template-w
I've wrestled with the same problem. I first render one of several
templates to a string, then include the string within a rendered
template. And my testing breaks (or at least is counter-intuitive) as
well.
It certainly doesn't seem right that rendering to a string dominates
(assert_template-w
Why not have RoR define a reference set of modules and class (call it
i18n for now) whose API implements the most basic i18n methods with no
real functionality? Then the plugins could flesh out the
functionality. I know this is pretty simplistic, but we need to start
somewhere. As RoR evolves,
81 matches
Mail list logo
