It means I'll have to change my models ! Seriously, #name is a method
in Class. So, we can't use it in models. #type is another. It means
we can't have Single Table Inheritance working.
methods = [ ActiveRecord::Base.methods,
On 1/8/06, Duane Johnson [EMAIL PROTECTED] wrote:
Here's a gentle nudge for ticket #1911 (more flexible fixtures). Can
we get this integrated soon?
Hi Duane,
This is a fairly major change to the current fixtures system. It
introduces some complicated error conditions (overlapping fixtures
I agree. Is it possible, David, that you kind of regret having put
it in there? The way you talk about it sounds like that's the case.
The flip side of this, is that if we remove it, we break existing
applications because on the off chance that an infinite redirect may
occur.
Also,
I have cleaned those now. I used Watir to visit the Edit screen for
every page, check the content for spam, and remove it if present.
If you can give us some regular expressions that you used with watir,
we may be able to protect the wiki with mod_security. This will at
least save us some
On 1/28/06, Kevin Clark [EMAIL PROTECTED] wrote:
I've got a patch ready adding the pagination tests (and confirming the
bug with :include). It depends on ticket 3606
(http://dev.rubyonrails.org/ticket/3606) so I'll submit it as soon as
3606 is checked in.
Kev
As the original author, Sam's
I've seen this and some other weird error in another project too. I'm
sure it'll get sorted out this weekend. Ulysses wasn't seeing any
errors, and I'm seeing two different errors in two apps. Very
strange.
I can reproduce this, I'll take a look into it. But I think it's
something
Which would include giving the monkeys complete access to the 37s
application code (because I think THIS is what all the patches get
tested against, I think). The problem is that there are tests which
are not included in Rails and are effectively proprietary, but 37s
(being the core
Rails is completely opensourced under the MIT license as far as I
know. There shouldn't be proprietary tests. Testing against
applications is good, but really, that is what unit testing is used
for in the codebase.
Amen.
Merge monkeys isn't necesarily the best course of action though. Does
On 2/7/06, Michael Schoen [EMAIL PROTECTED] wrote:
Got a handful of pending patches, most of them small tweaks to the
Oracle adapter. Should be quick work for somebody.
http://dev.rubyonrails.org/ticket/2446
http://dev.rubyonrails.org/ticket/3210
On 2/10/06, Kevin Clark [EMAIL PROTECTED] wrote:
I'll give it a shot. Is there a reason we can't load up the individual
schema to a db and use schema dumper? Clean up if needed?
Kev
It's also about making sure that the rake test_x loads the schema, and
runs the tests.
But I think you've just
Yep, I have the dbs set up right, MySQL 5.1.0 with InnoDB enabled on a fresh
SuSE 10 box. Most of the tests pass, I'll tinker with it and see what's
happening.
Curious if anyone on the core team tests outside of OSX? (Meaning, are the
tests known to pass in a non-osx environment?) The reason
to find a checkout that tested cleanly for me.
Weird.
/Lars
On Feb 10, 2006, at 8:15 AM, Michael Koziarski wrote:
Yep, I have the dbs set up right, MySQL 5.1.0 with InnoDB enabled
on a fresh
SuSE 10 box. Most of the tests pass, I'll tinker with it and see
While you're giving thought to that, what are your thoughts on renaming the
quote method inside of AR:B? Quite a few tickets come through for that as
well.
Unfortunately we have a lot of people calling the quote method from
plugins, custom code etc. We can't rename it without breaking
On 2/12/06, Nathaniel S. H. Brown [EMAIL PROTECTED] wrote:
I was just reading a blog post, about how PHP applications lack so much as
far as security goes, and it got me thinking that Rails should come default
secure, and you should have to force it to be less secure.
On that note, I came up
One idea might be to have any helper method to have a wrapper around it,
which is cleaned after using the %= method. Such an example,
Such as link_to(:controller = 'xss', :action = 'safe') in it's raw state
appends and prepends the {{SAFE}} and {{/SAFE}} string, which it's contents
are
1. I tend to think URL as a part of the user interface. If the user
look at (usually simple and structured in rails application) URL,
wouldn't she be confused by the seemingly random and very large
number assigned to her reply post? Topic's id #87 corresponds to the
87th-ness nature of the
I know that supporting composite keys is not a MUST, but it's a SHOULD.
Your invoice lines will have an invoice_id relating them to the
invoice, it doesn't get much more related than that. If you're
seeing the ids as anything other than serialised object-identity, then
you're over using.
The
So you're saying cool isn't a benefit in itself. ;-)
(But of course, I agree, if it's not backwards compatible it shouldn't be
done.)
I agree too, and the change currently being proposed is backwards
compatible for exactly this reason.
David's rake -T concerns wouldn't be reason enough to
We'd be happy to take on ActionWebServices, as we use it daily in
much of our business process. I had run into the issues in 1.8.4
but decided the benefits of AWS made 1.8.2 adequate for now. We
were unaware there was a maintainer vacancy. The 'we' i'm referring
to are myself, trey
Ok, found my problem, not sure if it's the same as yours -- locking
wasn't returning true if the update was successful.
Patch submitted:
http://dev.rubyonrails.org/ticket/4015
And applied.
--
Cheers
Koz
___
Rails-core mailing list
That is, setting a socket is the exception rather than the rule. For
most of the get-up-and-running apps I've seen, the socket isn't
necessary. Trying to set it is often an impediment to getting
started with Rails. But I suspect there may be downsides that led to
the decision to use a
On 3/6/06, Francois Beausoleil [EMAIL PROTECTED] wrote:
Hi !
Just wondering here, because if I define reader methods, then these
aren't used in the forms.
For example, I have this:
class Customer
def tax_rate
(read_attribute(:tax_rate) * 100.0).to_i
end
def tax_rate=(rate)
On 3/6/06, Rick Olson [EMAIL PROTECTED] wrote:
So, I sat down to use set_fixture_class, and it bombed on the first
thing I tried:
set_fixture_class :content_drafts = Article::Draft
I made a quick patch, and I'd appreciate a quick run through your
tests to make sure it doesn't disturb
On 3/13/06, Nicholas Seckar [EMAIL PROTECTED] wrote:
See [3857]
http://dev.rubyonrails.org/changeset/3857
Ah, yeah. Kevin Clark's refactoring of ActionPack's unit tests had
the same problem.
It really is strange behaviour ...
oh, and by the way, test:uncommitted? Nice!
--
Cheers
Koz
The tickets currently 'highlighted' for extra review by the core team
are in the following report:
http://dev.rubyonrails.org/report/19
If your favourite ticket isn't on that list, please add the
needs_review keyword so we can have a look. If one of the core team
removes the keyword, don't
On 3/14/06, Michael Schoen [EMAIL PROTECTED] wrote:
The changes to improve table aliasing in [3776] broke all sorts of
associations for Oracle.
The issue is that Oracle doesn't allow for table aliases using the AS
keyword.
... LEFT OUTER JOIN authors AS authors ...
is no good, but
Is there an easy way to rewrite the assertion so it works for folks not
in the Windy City?
I live in another windy city, so I noticed this too. I believe this
is now fixed as of [3870]. to_xml uses the xmlschema format (so
timezones are included) and the test now checks for the string in the
worksforme.
What other components do you have checked out? I must have to move
something into activesupport?
On 3/15/06, Michael Schoen [EMAIL PROTECTED] wrote:
Michael Koziarski wrote:
Is there an easy way to rewrite the assertion so it works for folks not
in the Windy City?
I live
Does the 'session' method do what you need?
http://rails.rubyonrails.org/classes/ActionController/SessionManagement/ClassMethods.html
On 3/24/06, Kyle Maxwell [EMAIL PROTECTED] wrote:
Hi all,
Rails tends to send the Set-cookie:_session_id... on every response,
when session handling is
Hey guys,
With the addition of has_many :through, a number of people will
probably want to add primary keys to their current 'rich association'
tables. Currently we don't have an add_primary_key. We have a ticket
for it[1], and I've attached a simple patch[2].
It works fine for mysql and
The reason I created this patch is explained in the ticket and that I
figured the :include route was a bit cleaner from a users perspective
than a combo of :select and :joins.
The patch no longer applies cleanly, and seems to cause quite a few
failures (unless I've screwed up the merge).
I have submitted a new patch file for
http://dev.rubyonrails.org/ticket/4132 that no longer produces any
conflicts or errors during the unit tests.
Applied
This is supposed to combine :include's in a compatible fashion since
they can either be an Array, Hash or a Symbol.
Shame that
On 4/4/06, Pete Yandell [EMAIL PROTECTED] wrote:
Let me sharpen up my first question, because I think it's essential
no matter how you approach this:
If I have a class that includes Reloadable, how can I declare a class
variable (or equivalent thereof) that persists across reloads of the
Just created a ticket for:
http://dev.rubyonrails.org/ticket/4673
Which outlines the option to merge/diff or patch on upgrade.
Currently I see the functionality of upgrading quite tedious, especially
with the now planned rapid release cycle. This is solely due to the fact
that I need to
As I see it, the reason to hide the internal api, from at least the main
api documentation, is that there are far more people interested in working
*with* Rails than there are people interested in working *on* Rails. For that
80 plus percent, having all the internal api docs mixed in with the
committed. Thanks
On 5/17/06, Adam C. Greenfield [EMAIL PROTECTED] wrote:
Looking to draw attention to #4955
(http://dev.rubyonrails.org/ticket/4955), it is a small nil handling
patch. I included a unit test in the patch. If there is anything else
it needs (or if it should be changed in some
The implementation involves some funky regex's on the sql sent along to
the connection adapter, so I'm going to do some more extensive testing
within my own app before posting to Trac.
I like the idea, however perhaps it's not ambitious enough?
If instead of doing the value interpolation
If you're overwhelmed with feature requests from a particular area, the
solution is not to force people to stop requesting. The solution is to use
Trac more effectively. Use filters, for christ sake! And it may be good idea
that some available Trac reports (
http://dev.rubyonrails.org/report)
Yup, I'm not against doing away with proper patches. I'm against
things like It'd be nice if scriptaculous had a helper to make a web
2.0 application for me.
Then I misunderstood the message completely. I am 200% on to wipe the
magic lantern patches.
In hindsight, I communicated poorly, I
Well, that is why I said that, if you filter them out, you need to create
separate reports for those. I never proposed for them to be cast aside and
forgotten, but if you don't deal with this then the effect will be the other
way around: they will make regular tickets sit ignored almost
I'm not entirely sure of the merits of having widely used plugins
report breakages back to the rails-core team. Some plugins are
notorious for fiddling with the internals of rails. Breakage there
is inevitable unless we freeze the codebase entirely.
Rails itself definitely needs some CI love,
Although the plugin author makes effort by packaging and releasing his stuff
to the community, not every plugin author will be able to support and
maintain his work on the mid or long term. As everyone here knows, the
coding part is only a slice in the lifetime of a piece of code, a tiner
slice
I think something like this may be more suitable for acts_as_legacy.
There are a myriad of enterprise naming standards (ZX_CST_ID__) and
we'll never support them all.
On 6/28/06, Obie Fernandez [EMAIL PROTECTED] wrote:
wtf? did I miss a previous discussion on this or something? That's an
ugly
On 7/5/06, Chris Mear [EMAIL PROTECTED] wrote:
Hello list,
In light of this recent change:
That's a strange change to embed in an oracle fix? Was it
intentional david? Michael?
http://dev.rubyonrails.org/changeset/4552
I personally don't like the change at all, the previous behaviour of
On 7/8/06, Kevin Clark [EMAIL PROTECTED] wrote:
I don't think we should reduce that sort of spam. The point is that
it's annoying so it gets fixed. Maybe we can put something in the
subject though so those of us who don't care about oracle and pgsql
breaking can filter it out?
I think it'd be
The ticket has a patch that shows how the API fits into the current
Rails code, with some fixes along the way (and more are coming).
We still haven't heard _a word_ from the core on the API.
Pretty please?
Hi Julik,
We have actually talked about this, sorry we didn't get back to you.
Trac's
On 7/17/06, James Adam [EMAIL PROTECTED] wrote:
Since the behaviour is different from that of create (i.e. no object
instances are returned), why not just define a new method which
clearly indicates it's aptitude for inserting large amounts of data?
Model.import(hashes) or something...
The
Is there a reason why AR doesn't pass the guess year flag to parsedate when
casting columns? Seems to me, in the context of a DB date field, you would
always want the 4 digit year.
Right now, if you shove a date like: 07/18/06 to Rails, MySQL will get
0006-07-16, but
I'm in the process of fixing this, however trac and I have a
disagreement on whether or not it should work.
Any attempt to update the report appears to just delete the sql query.
I'll have someone else have a look at it, but in the meantime the
situation is now ... significantly worse ;)
On
Hey guys,
Rails has been around for a while, and it's about time we got serious
about deprecating APIs which we no longer intend to support. Without
getting into a discussion about which code precisely is going to be
deprecated, I thought I'd describe what's going to happen.
If you run your
That would depend on how they decide to implement it. If they use the
same method to warn about all deprecations, changing it to raise
would be as simple as overriding that method.
This has been committed now.
As you can see from deprecation_test.rb in activesupport, it's fairly
easy to
Performance hurt. Having write_attribute mark dirty[attr] = true
would be great, but attributes may be modified in-place once they're
read, so we have to hash or copy them and look for changes.
A seductive alternative to is to treat attribute values as immutable
- freeze the value returned from
p = Person.find(:first)
p.school # nil
p.school_id = School.find_by_name('High School').id
p.school.name # High School
You should be assigning .school= here. Why are you working with the id?
p.school_id = School.find_by_name('Primary School').id
p.school.name # High School = Shouldn't this
I have a need to add additional conditions to the automatically
generated routes. Has anyone else come across this? Are there any
solutions in the works or any that people have already found?
What's the need that you have?
--
Cheers
Koz
___
For example I just submitted a documentation patch
(http://dev.rubyonrails.org/ticket/5762) for the :from option for the
ActiveRecord find method. I'd think that adding support for this
option should have had documentation associated with it when it was
added to begin with.
Just me 2 cents.
So here's my question... why does update_attributes run a new SELECT query,
and why is it using all those unnecessary conditions? I was even running
into an issue where sometimes the SELECT query wouldn't find what it was
looking for and therefore the update never happened (which is why I started
I agree that the patch has some junk on it, sorry. I'll clean it up
and post in trac.
I haven't found any satisfying inheritance plugin out there and imho
it would be nice if AR would support other inheritances types right in
the core, but even if there's no intention of incorporating other
Kent,
We're working on it. 1.1.6 should fix it I believe. Someone on the
core chime in?
Yes, 1.1.6 is not vulnerable as far as we can tell. In future, this
list is *not* the place to report vulnerabilities. Perhaps we should
have a [EMAIL PROTECTED] which contacts a few of us on the core
58 matches
Mail list logo
