Re: [Rails-core] AR unit tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 23, 2005, at 12:31 PM, Michael Schoen wrote: The test adding in [3089] passes under Oracle, but spits out some ugly stuff. Is this expected? Yes; it's expected. I will silence the warnings. It's to ensure than we don't generate reader methods for columns whose names are not valid Ruby method names. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDhNQvAQHALep9HFYRAmS9AJ4qu7L6032/t2/CQDE+WcNlY65oYgCeJUad qJtQgFp3/R4yS4ExaH667mU= =UTxA -END PGP SIGNATURE- ___ Rails-core mailing list [EMAIL PROTECTED] http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Changeset 3169 causing errors in my model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The mutual dependencies error introduced in [3169] is fixed in [3181]. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDhhwpAQHALep9HFYRAjLbAKDGdIo6Mt/lbhYPBQbQwL9vQWcT8wCeP35o Yxalq/jkefkiUm1DKqaZKYI= =Y2fT -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Changeset 3169 causing errors in my model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 24, 2005, at 12:00 PM, Francois Beausoleil wrote: 2005/11/24, Michael Koziarski <[EMAIL PROTECTED]>: SystemStackError isn't the user experience we're after though... Was there anything in your logs warning you that you'd overridden transaction? Nope, and I have had the same kind of error with other base class methods: quote, transaction. Bummer. The whole point of this warnings stuff is so that you get a message in your logs telling you that you're overriding an existing method. If you're on FastCGI, the message will appear in your web server's error log, not in development.log. This is known; we need to redirect STDERR to the current environment's logfile. Or even STDERR.reopen(File.open(configuration.log_path)) configuration.logger = Logger.new(STDERR) jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDhh7uAQHALep9HFYRArSDAJ9gU8K+qHbyThWm3uGG0iZsd8X2mACguXq+ aTUQ8L+2iAckSruEnmenmvI= =PGSd -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] question on enable_warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 24, 2005, at 12:06 AM, Michael Schoen wrote: In [3169], a change was made to enable warnings on the first load of a file in dev mode. Seems to result in a LOT of warnings from within Rails, particularly ActiveRecord (see below for a sample). If the "on first load only" part not working? Is there a way to make AR warnings-safe? The "on first load only" works. Getting AR warnings-safe will take more work. Check out the other [3169] thread :/ I think since this bothers enough people running on trunk, I will disable it (if false, ha!) until I have enough of the warnings cleaned up. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDhh/7AQHALep9HFYRAtyUAJ9lwy8gjPzsRf5uGurK2AHvXK7sawCgpd5f /hkTQhBNHroArKN6I/JsDqM= =dfvO -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Changeset 3169 causing errors in my model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 24, 2005, at 12:35 PM, Francois Beausoleil wrote: 2005/11/24, Jeremy Kemper <[EMAIL PROTECTED]>: Bummer. The whole point of this warnings stuff is so that you get a message in your logs telling you that you're overriding an existing method. If you're on FastCGI, the message will appear in your web server's error log, not in development.log. This is known; we need to redirect STDERR to the current environment's logfile. Or even STDERR.reopen(File.open(configuration.log_path)) configuration.logger = Logger.new(STDERR) I do not address this case in my patch, but you may check out what it does: http://dev.rubyonrails.org/ticket/3005 I took the liberty to up the priority and the severity. This is a serious issue that I faced myself multiple times. Thank you; the patch looks good. I'll be away for a bit (holiday) but another committer will likely merge it to trunk and the stable branch. Extra thanks for unit testing your patch. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDhii4AQHALep9HFYRApMCAJ4sFbxb1QQgbN45bsUD6J15cE5UlgCghwfe btPJAe7aC+XpVQsUjR4+pSg= =3c/b -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] connection specifications borked in changeset 3218?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 5, 2005, at 12:55 PM, Trevor Squires wrote: it looks like a recent change (3218) has borked connection specifications in some way. When I run my unit tests it fails because even though it's connection to the test database it's using the username (and I presume, password) of the *development* user. This does not occur in 3217 and, of course, it isn't a problem if you happen to use the same login and password for all three databases... By the way, does this sort of 'oops' thing deserve a TRAC entry as a first point of contact or is it ok to send these to this list? Please raise issues loudly and in every available forum :) I fixed the problem in [3222]. Thanks, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD4DBQFDlLZ0AQHALep9HFYRAqzgAJ9k9gESpeVoZKVY0gTxpGbuWpdbqACXTTUl YBuUT/QprG8ScYuJt4MmvQ== =ZUgP -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] #3024 - Reloading aggregation instances
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 5, 2005, at 4:14 PM, Francois Beausoleil wrote: Another patch that I feel needs more attention: http://dev.rubyonrails.org/ticket/3024 This patch ensures aggregations are reloaded when the parent record is. This bit me during unit testing. I was going bonkers thinking there was something wrong with my code. Anyway, this patch applies the same strategy as associations reloading. Worth taking a look and applying ? It includes unit tests too. I believe this is fit for trunk and stable. Applied. Look for it in 1.0rc5. Thanks for the patch (and tests!) Best, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDl70nAQHALep9HFYRAspiAJ0f1Jr/+D0TE8DUy1BHkkuKMH0CHQCcDl1s Nmd5Wumy2T82U0S+4O454QE= =6V/U -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] automatic db retries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 9, 2005, at 10:50 AM, Rick Bradley wrote: Not only that, but with 0.14.4 we've turned up a problem on Oracle with transaction isolation in tests. Basically, if we have a test that calls some AR functionality which happens to use a transaction internally, using use_transactional_fixtures, with 0.14.3 the changes in that test would be isolated, with 0.14.4 (on Oracle, but not on Postgres) the changes in that test are visible outside the test. We've gotten it down to a fairly small test pair and it's definitely a result of changes in oci_adapter.rb (which are almost entirely related to the new recoverable connections). When I have something clear enough to share I'll pass it along. http://dev.rubyonrails.org/ticket/3133 jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDmezXAQHALep9HFYRAuUPAKCPH9TwTkCCtboCierQR9uVFHv3lwCdEypS uK4M5TSZr3BrkfE4uJJyHV8= =UJPH -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] automatic db retries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 9, 2005, at 8:18 AM, Wilson Bilkovich wrote: Sorry to resurrect an old thread, but what about just defining a "no-op" query for each adapter. In Oracle, that would be, say, "select * from dual". Many Java connection pool implementations have such a thing, and execute it when a connection is assigned. If it fails, the connection is closed and reopened. If it works, it's safe to run your actual code. Retries are scary. This is how the feature's implemented: see the active? instance methods implemented by the various connection adapters. Currently, active? is called per-request. It'd be nice to cut that down, but it'd be at the expense of failed requests. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDme2OAQHALep9HFYRAqNMAJ9KAaPPPr6x0hM0vvDVYfVp9dsMTwCfaxxD 0vHt66epOb4Hfua1M1OHvaY= =HChh -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] config.frameworks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 12, 2005, at 11:21 PM, Kent Sibilev wrote: Can I ask you guys what is the point of having config.frameworks in environment.rb? According to the comment before this config parameter, it is there so you can specify which frameworks you don't want to use. On the other hand, if you use gem version of rails, and I believe most people do, whenever you require 'initializer', all rails frameworks are being loaded as a part of gem dependencies mechanism. So basically this config parameter is useless and confusing. Put your vendor/rails directory to work with rake freeze_gems or freeze_edge. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDnwv0AQHALep9HFYRAszzAJwIoUcZEfTmW4T/BGRyEqaTAyovrwCgjghx IMalZk0BV2bgWcECsBUc4vk= =81Sx -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] rails breaking with ruby rc 1.8.4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 13, 2005, at 9:39 AM, Ara.T.Howard wrote: this kind of thing exists in other places in the code as well. here are summaries of the two stack traces when this code is loaded: [...] yikes. basically what is happening is that Callbacks gets mixed into ActiveRecord::Base __twice__ - setting up a recursive defintion of #instantiate (the second time). Thanks for the detective work, Ara. It's interesting that defined? (Foo::Bar) results in a const_missing call for Foo but defined?(Foo) does not. now, why this seems to be platform dependant i do not understand yet - but the combination of autoloading hooks, require overrides, and non- protected (unless defined?...) class defs and method aliases seem fragile. Yes! I am so eager for Ruby 2 to obviate their need. i'm trying to fix - but it seems a wholesale revamp of the loading methods and definition strategy is in order. on the otherhand an __early__ subversion of require to occur exactly once no matter what might short circuirt the whole thing... I'd like a Module#wrap_method in Active Support to DRY up the repetitive, error-prone aliasing and give us a single place to more thoroughly check for double-wrapping. A robust require_once would be a good adjunct. Perhaps we could directly backport what's been done in 1.9 to ensure future compatibility. Best, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDnxB5AQHALep9HFYRAn/1AJ0cz+GgbBjHkdSzi8K1LElEYrLK0gCglGi7 KLmjt5WowO7TrjZYUp9xrEA= =bBh6 -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in has_many count?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 19, 2006, at 9:30 AM, Michael Schoen wrote: construct_sql is executed in the initialize method of the association and it handles the substitution of the sql. Ah, thanks. So the bug is that it doesn't do the right thing if the finder_sql has newlines (the regex needs to be modified). I'll submit a patch. Nice catch. jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDz/bVAQHALep9HFYRAvjVAJ4ldM8k7scs38737DrKkKtdEejOsACcC8uY g6V+LO2Q/8/+j7B1cMDmYrU= =7unY -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in has_many count?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 19, 2006, at 12:59 PM, Michael Schoen wrote: construct_sql is executed in the initialize method of the association and it handles the substitution of the sql. Ah, thanks. So the bug is that it doesn't do the right thing if the finder_sql has newlines (the regex needs to be modified). I'll submit a patch. Nice catch. Um, so even with this patch I'm not totally happy, but the fix is Oracle-specific, so not sure if it belongs in the core. When I'm using finder_sql, it's often because I've needed to supply a sql hint to get the right performance (isn't Oracle grand). So my finder_sql is something like... "SELECT /*+ INDEX(FOO$I) */ * FROM ..." Unfortunately, when this gets auto-converted into counter_sql, the hint gets wiped away as well. And if I needed a hint for the find, I also need a hint for the count. Would you be open to a patch that made the regexp uglier but didn't kill the sql hint? Or should I just specify both finder_sql and counter_sql? Sure. I think we should try to preserve SQL hints if only for the next programmer to come along with the notion that Rails will eat his hairy custom SELECT and grin right back. Plus, MySQL has a similar hint syntax, and every patch lends a welcome bit of polish.. Thanks, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFD0A1ZAQHALep9HFYRAr9OAKCnngbZ+3TA6n3oa9GgYOuS4b5GHgCcDsSw Sqgj4NzHCNMd3zeXlr+pTpE= =O++C -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] How should we do away with the rubysess white page of death?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 26, 2006, at 8:40 AM, Duane Johnson wrote: Jamis Buck and I had a few ideas tonight that would each take care of the CgiRequest bug where switching between Rails apps that have different classes (models) stored in the session causes the whole app to crash without a trace. Of course, the problem is only present when using the FileStore to store session data, since if the sessions are being stored in the DB, there shouldn't be any conflict between apps. The rubysess. file prefix and cookie names are configurable so the app generator may: class ApplicationController < ActionController::Base session :prefix => '<%= @app_name %>.', :session_key => '<%= @app_name %>' end Best, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFD2P+WAQHALep9HFYRAqVSAJ928/lFoLHCe1SrnrR+nAd7RctMDwCfeV7D yFy6xwYnXVegjuhe3T5GWqI= =jaQX -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Edge + Webrick + Helloworld now fails
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 27, 2006, at 4:04 PM, Kyle Maxwell wrote:
This stopped working rather recently.
NoMethodError in #
undefined method `verify!' for {}:Hash
RAILS_ROOT: script/../config/..
Application Trace | Framework Trace | Full Trace
./script/../config/../vendor/rails/activerecord/lib/active_record/
connection_adapters/abstract/connection_specification.rb:71:in
`verify_connection_cache!'
Very recently!
See http://dev.rubyonrails.org/ticket/3979
jeremy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFEA5Y0AQHALep9HFYRAr1zAKCkV3MrB51aFPi1DMwDyIIN6l1pVgCgq9Zs
lh6op/afDzcShgNwYzwUt3w=
=HjA9
-END PGP SIGNATURE-
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Rails 1.1 is coming
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 27, 2006, at 6:24 PM, Bob Silva wrote: I'll also have the date_helper patch updated to trunk tonight. Not sure what's wrong with it yet but bitsweat asked for updated tests against trunk so... Hey, it simply doesn't apply cleanly to trunk. The patch looks great. Thanks, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEA7YgAQHALep9HFYRAoeGAJ9E/L8qwYC9kpMxAjtHzIAoje8w4wCgwIQR Nsqt66FFvOVbWucAlhVvHAI= =uu2L -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Edge + Webrick + Helloworld now fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2006, at 9:12 AM, Tom Ward wrote: On 2/28/06, Stefan Kaes <[EMAIL PROTECTED]> wrote: Tom Ward wrote: A second line of attack is the allows_concurrency flag itself. I can't think when you'd ever want it to be false. FCGI is single threaded. By having the flag, we can optimize AR for single threaded apps. True, but to me the existing optimization extremely premature. With allow_concurrency = true @connection_cache is a hash of hashes, while when false its just a single hash. The only saving (when running single threaded) is a single hash lookup. This can't be worth the extra complication in the code, can it? I agree, Tom, particularly when we pay the price in brittle code. For now, I'm removing the setting from the webrick server so folks can continue working with trunk. I'd like to see allow_concurrency wiped out. Best, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEBJ4QAQHALep9HFYRAsVCAJ93dpY8dOwyqypoqDyQWMw4UcSUpwCfTv5H +B4cSCukjurm3euWZBo+8Sg= =KNlX -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Database Adapter Plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 28, 2006, at 11:40 AM, Derrick Spell wrote: With all the talk of 1.1, and with all the patches being applied, I realized that my laziness (or lack of free time, depending on your perspective) means that my OpenBase database adapter will most likely not make it into 1.1. This is mainly because I never got around to making it a plugin so that it could be throughly tested by the OpenBase community before being committed. Well, I'm finally motivated... Do you think the adapter is ready for 1.1? Are you prepared to maintain it? ;) I'd prefer to include it in the release (perhaps with caveats?) if it's feature complete modulo migrations support. The Firebird adapter took a similar path into Rails 1.0. Best, jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (Darwin) iD8DBQFEBLgfAQHALep9HFYRAq9IAKCY+eyn3LyqEvDwwkINfyzuyaK9CACfbYOH aFM0w5au7/CD6kyvIbbbJ2g= =TC2U -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Use svnmerge.py for merging trunk to stable branch
On Apr 7, 2006, at 12:29 PM, Blair Zajac wrote: Now that Rails has a stable branch, I would like to suggest considering using svnmerge.py to manage the revisions in trunk that you want to pull over into the branch. It'll make life much easier in managing commits to trunk and then merging them to stable. I've been using svk to similar effect. It's great. http://svk.elixus.org jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Issue in ActiveRecord generated reader methods
On May 9, 2006, at 6:12 PM, Jonathan Viney wrote: I agree that seems odd. I can't see any reason not to use read_attribute there, as it will type cast if necessary. define_read_method could be simplified and Column#type_cast_code should be unnecesary perhaps. Inline type casting tailored to each attribute's column type is faster than does-it-all read_attribute. It's for performance alone: you may disable generated readers with no loss of functionality (though you may consider generating your own..) jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Re: Rails AR/Oracle Unit Test: [4335] failed
On May 11, 2006, at 10:19 PM, Michael A. Schoen wrote: This can be fixed by enhancing the test to support Oracle's sql type for integer, which is NUMBER(38), but this test also exposed a difference in how the Oracle adapter is handling sql_type, and I'd like to just fix that. I'll have a patch submitted by tomorrow that'll fix this. Each database seems to handle integer limits differently (number of bytes vs. digits), so I removed the additional test cases since the limit isn't cross-platform anyway. Guess I could have left MySQL in.. Please do update if you add specialized :limit handling for Oracle as well. Thanks! jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] real bind variables
On May 25, 2006, at 3:07 PM, Michael A. Schoen wrote: So I've finally bitten the bullet and patched the AR Oracle adapter to use real OCI bind variables. This has a measurable impact on the client side, and a huge impact on a high volume Oracle server due to the sql hard parses that it saves. I assume bind variables and prepared statements are orthogonal. 2. Do other db's support a similar concept with a similar benefit? Should this functionality be implemented at a higher level (ie., in the abstract adapter) to make it usable for other dbs? Yes: the native postgres bindings support bind variables. In any case, we can move the existing behavior to the abstract adapter as a fallback. As an aside, only the pretty comprehensive AR unit tests make a patch like this even possible to think about. So kudos to everyone on that point. And kudos to you! Thank you for your conscientious maintainership. jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Routing rewrite, checked in
On Jun 1, 2006, at 12:04 PM, Rodney Ramdas wrote:
hi
this seems to give issues:
simply doing,
def helper_routes
with_routing do |set|
set.draw { set.connect ':controller/:action/:id' }
[..]
end
end
throws
NoMethodError: undefined method `connect' for
#
i don't quite get why since RouteSet#draw simply yields to Mapper
which does connect.
Use the map that set.draw yields:
with_routing do |set|
set.draw do |map|
map.connect ':controller/:action/:id'
end
end
jeremy
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] rubygems support for rails plugins (patch)
On Jun 16, 2006, at 1:26 PM, John-Mason P. Shackelford wrote: Rails committers, (feedback from others welcome) Would you accept a patch--in principle, obviously the implementation matters--that would: Yes. Gems are a great fit and the reason we've pushed back on proposals such as dependency management (wheel redux). 1. allow Rails to load a plugin from gem How does this look? Is there a manifest of gem plugins + versions in vendor plugins? A 'stub' plugin per gem? 2. permit the plugin script to install them How can the script distinguish rails plugin gems? script/generate looks for a _generator suffix -- brittle and ugly. Gems could use richer metadata here (even as simple as tags.) Another way is to host a plugins-only gemserver at plugins.rubyonrails.org 3. give the plugin generator's default Rake file the ability to package and publish a gem 4. introduce freeze/unfreeze for plugins Cool. Why? - RubyGems's handling of dependencies and updates is mature. - When I am writing my own plugin I want the source in my project, but when I am using other people's code I want to express that as an application dependency. - Some Rails plugins have a life outside of Rails, e.g. models that get used by non Rails apps. I agree. I'm interested to see how RubyGems manages the task. Best, jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] simply_restful plugin
On Jun 28, 2006, at 10:18 AM, Zack Chandler wrote: I love the simply_restful plugin (beautiful work Jamis) but wonder why the naming convention changed to look for pluralized controllers by default. If you do: map.resource :message then you must have a MessagesController. If you already have a MessageController you need: map.resource :message, :controller => 'message' which is slightly less DRY. Is this a change in convention to pluralize controller names? Almost all the examples in the docs and rails books use singular controller names. I'd be happy to make a patch if this is an unwanted side-effect of the plugin. simply_restful addresses collections of resources and their members so pluralization feels natural. (The scaffold generator has used pluralized names for months, too.) jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Re: [Ruby on Rails] #5544: [PATCH] Add underscore_table_names option to ActiveRecord::Base
On Jun 29, 2006, at 3:36 PM, Obie Fernandez wrote: I think my patch is merited, but if nobody else thinks so then I'll defer to the wisdom of the group. That said, the workaround provided by bitsweat doesn't make sense to me. I wonder if perhaps I didn't get my point across in the description. Oh and I don't quite understand how it is pleasantly pluggable either. Looks like a total hack to me. It's not a total hack workaround, it's a feature! Passing a block to set_table_name is an ugly dog (the cache var doesn't help) but it's there so you can transform the default table name as you like. A plugin is natural considering the usage you want is uncommon and covered by the public API. jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] help finishing a patch for label helpers? [#362]
On Jul 5, 2006, at 5:43 PM, Peter Michaux wrote: Rick, it looks like a little more than hacking. What is stopping your patch from going into the core? (BTW, you quoted his answer just a few lines up.) I use labels too and would like to see them in the standard form builder. jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Showing SQL Server some love...
On Jul 7, 2006, at 6:51 PM, Ryan Tomayko wrote: On 7/6/06, Tom Ward <[EMAIL PROTECTED]> wrote: There are a fair few issues against the SQL Server db adapter that I'd like to see fixed. There are also a couple of features I'd like to add, but don't really want to until these bugs have been fixed. It's time to show SQL Server some love! Tom has arguably contributed every bit as much if not more to the apapter as myself so I'd like to nominate him. He was probably the right guy for the job months ago. Thanks for all the work you've put into the adapter, Ryan. Good luck migrating away. So, Tom, you looking to be a bug magnet? ;) jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Float -> BigDecimal
On Jul 8, 2006, at 11:00 PM, Michael A. Schoen wrote: But just wondering if folks considered the performance impact of the change? From a simple test it seems that BigDecimal math is about twice as slow as using Floats. BigDecimal is slow, but numeric(10,3) ought to be meaningful. Anyone tried LongDecimal? http://rubyforge.org/projects/long-decimal jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Testing has_many :dependent => :restrict
On Jul 26, 2006, at 6:06 AM, Daniel N wrote:
I've had a crack at this one and it is as I feared.
If I define the restrict association first, then the destroy chain
is halted and all is well. But if I have an association where
a :dependent => :destroy is declared before the association
with :restrict then the first association is destroyed before the
destroy chain is halted.
You can wrap the destroy method to leapfrog the callback chain.
associations.rb, configure_dependency_*
case reflection.options[:dependent]
when :restrict
class_eval <<-end_eval
def destroy_with_has_many_#{reflection.name}
unless #{reflection.name}.blank?
raise DestroyRestricted.new(self, #
{reflection.name.inspect})
end
end
alias_method_chain :destroy, "has_many_#{reflection.name}"
end_eval
# ...
end
base.rb
module ActiveRecord
class DestroyRestricted < ActiveRecordError
def initialize(model, by)
super "#{model.class.name} #{model.id} destroy restricted by
#{by}"
end
end
end
I have taken my first real plunge into the rails source and found a
number of places where I thought a transaction might go to prevent
this but to no avail. Actually my head is spinning a bit trying to
put all the pieces of active_record together.
For this to work I think I need to put a transaction around the
entire destroy chain, but I have no idea how to do this.
Any pointers anyone could give would be great.
destroy and its callbacks are wrapped in a single transaction (see
transactions.rb) so you can raise an exception to rollback.
example:
class ParentController < ApplicationController
def destroy
@parent.destroy
redirect_to parent_url(@parent)
rescue ActiveRecord::DestroyRestricted => restricted
flash[:error] = restricted.message
redirect_to :back
end
end
Best,
jeremy
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Testing has_many :dependent => :restrict
On Jul 28, 2006, at 8:29 PM, Daniel N wrote:
Just a thought tho. By raising an exception, this would put
destroy into a different category, this should perhaps be destroy!
to fit with the other methods that raise errors.
Good call. Really, destroy_with_callbacks should rollback the
transaction when a before_destroy callback is false rather than
returning false and committing. Then the implementation simplifies
back to
case reflection.options[:dependent]
when :restrict
class_eval "before_destroy { |model| model.#
{reflection.name}.blank? }"
jeremy
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Re: Why are has_one objects resaved when the parentis saved?
On Jul 28, 2006, at 11:22 PM, Josh Susser wrote: The other way to do dirty checking is to do it on an object basis, instead of by columns. I'd love to be able to track what associated objects had been modified so that when I save an order, all the line items that got modified get saved too. Then of course I'll want an identity map in AR so that I don't have multiple, possibly inconsistent model objects floating around for just one record. I think I can see a good way to do the identity map, but only the vaguest idea of how AR might save dirtied children automatically. Would these things be PDI-level enhancements, or a waste of time to look into? I recall Jamis did object-level dirty checking by MD5ing attributes. Search for 'smart saves' on trac (when it's back with us, the living- breathing.) jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Re: Why are has_one objects resaved when the parentis saved?
On Jul 28, 2006, at 2:04 PM, Marcel Molina Jr. wrote: On Fri, Jul 28, 2006 at 01:07:59PM -0700, Bob Silva wrote: I'm curious to know if "dirty" checking was considered during the design process of AR. It would add performance benefits (configurable?) for larger tables and associations in a write heavy environment especially if you have text or blob fields in your tables. Anyone care to PDI this as a plugin? As I remember it, about a year ago Jeremy Kemper implemented dirty column tracking and decided against it for reasons I forget. Something wasn't right in the cosmos though. If I am remembering correctly, maybe he could share what the issues were before someone dives into implementing a plugin for this. 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 read_attribute. Then we're on easy street. jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] error on ticket submit
On Aug 1, 2006, at 1:34 PM, Michael Genereux wrote: Are all new, noncritical patches on hold for right now pending the new ticket page? I've started editing documentation in the core Rails classes to make them more clear, fix typos, and in some cases, fill in undocumented public methods. Speaking of which, is this what David wanted at RailsConf when he asked for more documentation? I interpreted as such and then, after I'd done some work, I realized he may have meant the HOWTOs in the wiki. Can someone on the core team give me clarity on what they would have a warm body do if they had them once a week for eight hours? I'd like to see the docs thoroughly reviewed against the source and expanded with concise examples from the wiki et al. Think of the process as rcov for docs - the behavior of a method should be transparently and completely reflected in its docs. See AR associations for some poor examples (Dave T ran into considerable ambiguity documenting them for agile2.) Interestingly, something that'd make documentation easier and clearer would be more managable unit tests. Since a method's tests are our ultimate measure of its expected behavior, good documentation starts there. Tests are roughly organized but a jumble when it comes to "where is method X behavior tested?". Break em up those ice floes and reorganize similarly to Active Support's lib layout. Thanks Michael - jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Adding :having to Active Record
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 4, 2006, at 11:19 PM, Blake Watters wrote: I have recently needed support for having clauses for some advanced find queries in my application. I've implemented this in a mixin that implements a new set of finders and query constructors that mirror the core Active Record, except for the additional support for :having as an argument. This has reached stability and now works with eager loading and scopings, so I'd like to extract it from my application as a patch against Active Record core. I thought I would talk this through before producing a patch and missing the mark and having to refine, so a few questions: 1) Can I confirm that :having feels like core functionality? I see that it is part of the calculation module already, but I need it to restrict my find results set and not just perform counts and so forth. Basically I am performing a join and want to use :having to check that the joined results match a threshold (i.e. HAVING count (visits.id) > 0). Sounds good, Blake. Do have a patch, or is it tied into your app? 2) I have identified the following places where :having needs to be added: associations.rb - construct_finder_sql_with_included_associations base.rb - construct_finder_sql base.rb - validate_find_options construct_finder_sql + :having is enough to support Calculations too, so we can DRY out its duplicate sql construction. Anywhere else that I am missing? 3) I believe the following tests to be necessary for a good patch, what am I missing? - vanilla find with having, single table - find with having, with join tables. Having against base table - find with having, with join tables. Having against join table - find with having, using scope - find with having, using eager loading + behavior in nested scopes 4) Documentation. Update the doc blocks to include the key and document in the patch ticket? Yes, please. 5) Errors. Do I need to provide any validation on the arguments or new errors or can I just let AR blow up with exceptions if you ask for a boneheaded query? The group clauses here become very important. You can just let the db raise exceptions as usual. 6) I develop on MySQL exclusively. What kind of cross database problems do I need to consider? (i.e. I haven't researched that having clauses will work everywhere). Is there a database specific element to what I am trying to accomplish? Please give PostgreSQL a shot. If it works there, it's likely to work elsewhere. Thanks! jeremy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE1P8AAQHALep9HFYRArNaAKC+/XtvYvBJVaTTCxxTxnPh208CxgCgxGmA 6L2i1CzUeh+jP1s7z9GTA+Y= =wp+t -END PGP SIGNATURE- ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] documentation
On Aug 8, 2006, at 3:47 PM, Michael Koziarski wrote: 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. Trac could probably be updated to include this. But I certainly don't apply patches which don't have test cases *and* documentation. It's already our process, but should probably make it explicit to save shotgun submitters some time. How about two new ticket resolutions: untested undocumented to put some shorelines our brimming, open sea? Anyone may resolve untested and undocumented tickets as such. Anyone may reopen when satisifed. Sprinkle with reports to assist those who want to team up either. jeremy (I considered 'unverified' and 'unimplemented' for bugs/patches too - maybe too much? :) ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Fix for cascading includeded associations
On 8/13/06, Rich Collins <[EMAIL PROTECTED]> wrote:
I noticed that you can't cascade an include more than twice on thesame association (for has_many at least). It seems that theassociation name table alias is used as a key to store the number oftimes that the association has been used in the include. This allows
the alias to change for each subsequent join. However, the way thatthe code was written caused a new key to be used each time the aliascount was incremented. As a result, you could not cascade more thantwice on an association:
Tree.find(:first, :include => {:children => {:children => :children}})The attached diff fixes this issue and passes all unit tests.Thanks Rich!
http://dev.rubyonrails.org/changeset/4758 (trac willing)jeremy
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] More changes to cascading associations
Is this a patch against trunk, which includes your previous patch?On 8/15/06, Rich Collins <[EMAIL PROTECTED]
> wrote:I added additional fixes to recursively cascading associations. This
patch includes fixes for has_many :through and habtm (with tests) aswell as tests for has_one and belongs_to. I created some new modelsfor testing and added the required sql for creating and dropping thetables. This is _only_ tested on postgresql.
As a quick summary, here are some examples that previously would notwork and are now tested and/or fixed:root_node = RecursivelyCascadedTreeMixin.find(:first, :include=>{:first_child=>{:first_child=>:first_child}}, :order => '
mixins.id')leaf_node = RecursivelyCascadedTreeMixin.find(:first, :include=>{:parent=>{:parent=>:parent}}, :order => 'mixins.id DESC')source =
Vertex.find(:first, :include=>{:sinks=>{:sinks=>{:sinks=>:sinks}}}, :order => 'vertices.id')sink = Vertex.find(:first, :include=>{:sources=>{:sources=>{:sources=>:sources}}}, :order => '
vertices.id DESC')___Rails-core mailing listRails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] test::unit namespace pollution
On 8/15/06, court3nay <[EMAIL PROTECTED]> wrote: Background: I've got an app that doesn't use the DB (long story..)and running tests is certainly a chore when you don't have any DBconnection.Also, due to the way rails extends TestCase, running tests in your suite that aren't tied to AR can have issues.Part of the solution involved renaming the main test class, such thattest_helper becomesclass NoDbTest < Test::Unit::TestCaseand all the unit and functional tests inherit from NoDbTest. I propose that rails' test class inherits from, rather than extends,Text::Unit::TestCase.Someone had a patch to skip the db if the database config is empty or no fixtures are declared. It broke the internal AR tests, but that could be worked around by providing a dummy config. It'd solve your immediate problem.Rails should do the right thing with TestCase but getting there demands a painful deprecation step nobody's eager to take. jeremy ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] More changes to cascading associations
On 8/15/06, Rich Collins <[EMAIL PROTECTED]> wrote:
Yes. I did an update before I did the diff.Ah, appears the attachment is the same diff as the last patch. Could you pass along the new patch?Thanks,jeremy
On Aug 15, 2006, at 9:18 PM, Jeremy Kemper wrote:
Is this a patch against trunk, which includes your previous patch?On 8/15/06, Rich Collins <
[EMAIL PROTECTED] > wrote:I added additional fixes to recursively cascading associations. This
patch includes fixes for has_many :through and habtm (with tests) aswell as tests for has_one and belongs_to. I created some new modelsfor testing and added the required sql for creating and dropping the
tables. This is _only_ tested on postgresql. As a quick summary, here are some examples that previously would notwork and are now tested and/or fixed:root_node = RecursivelyCascadedTreeMixin.find(:first, :include=>
{:first_child=>{:first_child=>:first_child}}, :order => ' mixins.id')leaf_node = RecursivelyCascadedTreeMixin.find
(:first, :include=>{:parent=>{:parent=>:parent}}, :order => 'mixins.id DESC')source = Vertex.find(:first, :include=>{:sinks=>{:sinks=>
{:sinks=>:sinks}}}, :order => 'vertices.id')sink = Vertex.find(:first, :include=>{:sources=>{:sources=>
{:sources=>:sources}}}, :order => ' vertices.id DESC')___
Rails-core mailing listRails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core___Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
___Rails-core mailing listRails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] More changes to cascading associations
On 8/16/06, Rich Collins <[EMAIL PROTECTED]> wrote:
Ah sorry I grabbed the old diff. Here is the new one with the proposed changes.Thanks - http://dev.rubyonrails.org/changeset/4776
jeremyOn Aug 15, 2006, at 11:09 PM, Jeremy Kemper wrote:
On 8/15/06, Rich Collins <[EMAIL PROTECTED]
> wrote: Yes. I did an update before I did the diff.
Ah, appears the attachment is the same diff as the last patch. Could you pass along the new patch?
On Aug 15, 2006, at 9:18 PM, Jeremy Kemper wrote: Is this a patch against trunk, which includes your previous patch?On 8/15/06,
Rich Collins < [EMAIL PROTECTED] > wrote:
I added additional fixes to recursively cascading associations. This patch includes fixes for has_many :through and habtm (with tests) aswell as tests for has_one and belongs_to. I created some new modelsfor testing and added the required sql for creating and dropping the
tables. This is _only_ tested on postgresql. As a quick summary, here are some examples that previously would notwork and are now tested and/or fixed:root_node = RecursivelyCascadedTreeMixin.find
(:first, :include=> {:first_child=>{:first_child=>:first_child}}, :order => ' mixins.id')leaf_node =
RecursivelyCascadedTreeMixin.find (:first, :include=>{:parent=>{:parent=>:parent}}, :order => 'mixins.id
DESC')source = Vertex.find(:first, :include=>{:sinks=>{:sinks=> {:sinks=>:sinks}}}, :order => 'vertices.id
')sink = Vertex.find(:first, :include=>{:sources=>{:sources=> {:sources=>:sources}}}, :order => '
vertices.id DESC')
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
