This probably happens because you're in development mode where
the AR model classes are not all automatically loaded, so if you find
through Order you only get Order and ItemCollection because neither
is aware of the existance of ReplenishmentOrder until it has been
loaded.
A hack fix for this is
nik.wakelin == Nik Wakelin
I'd suggest removing all non-alphabetic characters from all strings,
converting to lowercase and then using levenshtein distance or
something like that to see if there are more similiar names.
On E, 2008-10-27 at 16:14 +0100, Xavier Noria wrote:
> 3rd version. Same alg
They are likely the same person:
56 Tobias Luetke
47 Tobias Lütke
On E, 2008-10-27 at 14:41 +0100, Xavier Noria wrote:
> 2nd version.
>
> Counters have changed and grand total now is ~1400 people!
>
>http://pastie.org/301335
>
> Awesome!
>
> Reason is Pratik recalled in svn some attribut
lication by 5 req/s.
>
>
> Is there a reason for the current implementation?
The reason was to make Rails.env callable from inside the initializer
block (problem cause by the fact that AS is not loaded by railties
but is actually loaded later by AR).
Any ideas on how
On E, 2008-08-25 at 14:00 -0700, Hongli Lai wrote:
> I just want to say, good work. :) I've tried to use Rails with
> PostgreSQL some time ago and I ran into all sorts of issues. Hopefully
> these changes will get included in time.
Care to elaborate on the issues?
I'm not aware of any issues wit
> when 0..2; 'tinyint'
> when 2..4; 'smallint'
> when 5..6; 'mediumint'
> when 7..9; 'int'
> when 9..20; 'bigint'
This is exactly what the code used to be like.
Regards,
--
Tarmo Tänav <[EMAIL PROTECTED]>
--~--~
It was removed basically because there is no need for it:
http://dev.rubyonrails.org/ticket/11093
On L, 2008-06-21 at 04:06 -0700, Jonathan Wallace wrote:
> Hello,
> I was unable to find the commit related to removing attribute
> filtering in Rails 2.1. I'm interested in the reasoning as to why
type of primary
key to be an unsigned int.
Thank you,
--
Tarmo Tänav <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
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
d be configurable and at
least for older applications should not be changed?
Thank you,
--
Tarmo Tänav <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" grou
lowing:
>
> * changes the primary key data type for the MySQL adapter to be
> "int(11) unsigned"
Hi,
Why do you need unsigned integers and what happens if the values go
outside the range of signed integers, will rails fall back to
Bi
On L, 2008-04-26 at 13:10 +0100, Frederick Cheung wrote:
> I noticed that [8863] remove the :except and :only options from
> ActiveRecord::Base#attributes (and it makes perfect since not to
> duplicate Hash#except/slice in there). #attributes still takes an
> options parameter, but just igno
There was a Trac ticket about this:
http://dev.rubyonrails.org/ticket/9155
The problem could probably be fixed with one or more carefully placed
Thread#exclusive blocks. I don't think there is a good reason why
several threads have to be able to load new constants in parallel.
On K, 2008-04-23
On P, 2008-02-03 at 13:22 +1100, Matthew Palmer wrote:
> On Sun, Feb 03, 2008 at 02:21:27AM +0200, Tarmo Tänav wrote:
> > On P, 2008-02-03 at 10:51 +1100, Matthew Palmer wrote:
> > > On Sat, Feb 02, 2008 at 05:12:39PM -0600, [EMAIL PROTECTED] w
On P, 2008-02-03 at 10:51 +1100, Matthew Palmer wrote:
> On Sat, Feb 02, 2008 at 05:12:39PM -0600, [EMAIL PROTECTED] wrote:
> > Name:
> > test_group_has_many_through_should_use_group_for_count(AssociationsJoinModelTest)
> > Type: Error
> > Message: ActiveRecord::StatementInvalid: PGError: ERROR:
A count makes the database do a lot more work as it must count all
matching rows not just find the first one that matches. Depending
on the exact conditions used and the database schema/indices/size the
difference can be very large.
On R, 2007-12-21 at 14:13 -0500, Rick Olson wrote:
> > Well I en
On L, 2007-12-01 at 02:29 -0800, John Barnette wrote:
> All,
>
> I've been playing a bit with some patches to make the fixture loading
> and management code a little bit easier to maintain. If I were to
> start chopping out features, how would you feel about losing:
>
> Fixture instantiati
the table associated with
this class.
def columns
unless @columns
@columns = connection.columns(table_name, "#{name} Columns")
@columns.each {|column| column.primary = column.name ==
primary_key}
end
@columns
end
--
Tarmo Tänav <
Isn't this http://dev.rubyonrails.org/ticket/9051 ?
On E, 2007-11-12 at 12:14 +, Jacek Becela wrote:
> Hello,
>
> In User model:
> has_many :projects, :through => :authorizations
>
> In view:
> render :partial => @user.projects
>
> This blows up because HasManyThroughAssociation inheri
Looks interesting.
I don't have time to test this but have you tried to eager load several
has_many associations at once (so there are M*N result rows)
and compare the memory consumption of the new approach with the old one?
On P, 2007-10-28 at 18:34 +, Pratik wrote:
> Hi,
>
> I've uploaded
http://dev.rubyonrails.org/ticket/8562
On E, 2007-10-22 at 17:42 +, codesujal wrote:
> Hi,
>
> I've done a bit of googling and trac searching already for this,
> so apologies if this is already discussed or documented...
>
> I found a change that blew up a bunch of code for me. NOt sur
On L, 2007-10-06 at 12:52 +1300, Michael Koziarski wrote:
> On 10/6/07, Nathaniel Brown <[EMAIL PROTECTED]> wrote:
> > I suppose.. but reducing the site by any measure, especially what my
> > findings reported (25%), it seems like it is valuable. Food for thought.
>
>
> That 25% becomes about 0.
On P, 2007-09-30 at 20:34 -0700, [EMAIL PROTECTED] wrote:
> Dear Koz,
>Thanks for your reply; perhaps I will looking into submiting a test
> that shows the bug that Tarmo is describing on his very informative
> writeup at http://dev.rubyonrails.org/ticket/9253.
There are already tests attache
n sure anymore if that would be a good approach.
Perhaps the easiest fix would be to just let the adapters implement
insert_blank_statement() (so they could each provide their way of inserting
a blank row) and generate the SQL in AR::Base.create() in case there
are no columns to insert.
Any id
On T, 2007-09-25 at 21:58 +0100, Frederick Cheung wrote:
> You could probably get away with it quite a lot of time. I've waffled
> a bit about this http://www.texperts.com/2007/09/22/loading-fixtures-
> with-parsimony/
> The short version is that any time a test does something somehow
> conne
On R, 2007-09-07 at 17:48 +, Matt Aimonetti wrote:
> I just confirmed that solution works but it doesn't answer my
> question about update_all not using custom filters. Is that a bug or
> an expected behaviour? (I understand that technically unless you do a
> single query at a time, filters a
On R, 2007-09-07 at 15:19 +0200, Mislav Marohnić wrote:
> I don't really believe in this kind of security. You implement a
> destructive controller method like "destroy", and then you want to
> prevent access to it by cutting of the route? Why not solve it with
> proper access control, or simply d
On E, 2007-08-20 at 21:52 +1200, Michael Koziarski wrote:
> I've been kicking around a few more changes to AR::Base lately and
> perhaps we could do something along these lines. My thoughts on our
> querying at present are:
>
> * It should be in / near the adapters.
>
> There's already some code
On E, 2007-08-13 at 11:20 +0200, Jonathan Weiss wrote:
> I gave it a go on my local app test suite and everything is fine.
>
> +1 from me.
>
> Jonathan
>
Hi,
Could you add the +1 to trac? (and a verified keyword with it)
Thanks,
--
Tarmo Tänav
h is used when a row needs to be
created but there are no actual attributes, or the insert method
needs a condition to cover this edge case.
I'd like to implement this, but I'd first like to know which
approach (if any) I should take.
Thank you,
--
On E, 2007-08-06 at 09:55 +0100, Hugh Sasse wrote:
> On Fri, 3 Aug 2007, Tarmo Tnav wrote:
> > def silence(&block)
> > use_log_level Logger:ERROR, &block
>
> Wouldn't that need to be higher than ERROR, i.e. a new value, possibly
> called NEVER or something?
Not neccessarily, the silence method
On R, 2007-08-03 at 18:51 +0100, Hugh Sasse wrote:
> > I don't see a problem with having this functionality, but your
> > proposed interface seems a bit strange.
> >
> > Why do you really need the :silent, and :silence arguments?
>
> Trying to avoid some mysterious boolean parameter:
>
> http:/
Hi,
Have you created a ticket for this?
I don't see a problem with having this functionality, but your
proposed interface seems a bit strange.
Why do you really need the :silent, and :silence arguments?
They seem to create redundancy: silence(:silence), and don't
really provide additional usefu
You are describing object transactions, Rails used to have support#
for those, but it was removed [1] and is currently available
as a plugin [2].
[1] http://dev.rubyonrails.org/ticket/5637
[2] http://code.bitsweat.net/svn/object_transactions/
On N, 2007-08-02 at 09:02 -0600, Jonathan Younger wro
On E, 2007-07-30 at 15:45 +0700, Hendy Irawan wrote:
> Do you know any plugin which provide this behavior (i.e. disable
> constraints in Mysql/postgres/etc before fixture load, and enable them
> after fixture load successful, for every test case?)
>
> Or you have one?
>
> It'd be deadly useful!!
Haven't submitted a patch for the fixture thing but I have for
nested transactions. I'll provide the hotpatch but I don't
know how it would behave without my nested transactions patch.
This should go into config/initializers/
so it's like a plugin but only the ruby code.
http://tarmo.itech.ee/fix
On L, 2007-07-28 at 13:04 +0700, Hendy Irawan wrote:
> Tarmo Tänav wrote:
> > I'm not actually proposing a mixed system, 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.
> >
Actually there is currently pre-loaded fixtures support but if you
use it you lose the benefit of table_name(:fixture_name) accessors.
Basically the pre-loaded fixtures currently mean that rails does
not load anything into the database it runs each test inside a
transaction and then rolls the tra
ttp://rails.corefun.org/tasks/14 is a nice example of
the problem, if the patch had been applied at the correct
component level then it should have applied correctly.
Also it shouldn't hurt to try to apply the patch with
-p1 after -p0 fails with files not found.
--
Tarmo Tänav <[EMAI
On E, 2007-07-23 at 05:51 +1200, Michael Koziarski wrote:
> > Right now, the fixture-scenarios plugin is a step in the right
> > direction, but I wouldn't mid joining in in an effort to replace the
> > current Fixture system in rails completely, hell, I wouldn't mind it
> > breaking backwards-inco
On K, 2007-07-04 at 11:49 -0700, Jeremy Evans wrote:
> You can already do what you want (assuming it hasn't changed since
> 1.2.3), but it is ugly:
>
> :conditions=>'#{"#{aliased_table_name}." rescue ""}attribute = value'
>
> You need the rescue because aliased_table_name isn't available when
On K, 2007-07-04 at 20:55 +1000, Daniel N wrote:
> I've been thinking about this issue myself and have thought of how I
> would like to use it, but I have not worked out how I could patch it.
> I hope I'm not way off the conversation here. ;)
>
> Basically I have been thinking that if a hash is
This is an issue also described in rails ticket #6924 [1]
Simple :conditions on associations work very well when associations
are loaded separately, but they don't work so well when eager
loading is used and either several tables use the same field name
or the more extreme case of the same table
42 matches
Mail list logo
