[Rails-core] AR: Quoting in Join Model Test
Greetings made men of rails! I am presently writing a new database adapter for rails to bring the OpenBase community on board. In working through the rather extensive AR tests (which I very much appreciate), I have come across a question I can't seem to answer on my own. In the test_has_many_with_piggyback(AssociationsJoinModel) the result is expected as a quoted integer "2". My adapter is returning it as an unquoted integer. What I can't figure out is why this is expected to be quoted. Since these little things are sometimes symptomatic of a larger, more fundamental problem with the way I'm handling things, I thought I should ask. For your convience, here is the test in question: def test_has_many_with_piggyback assert_equal "2", categories(:sti_test).authors.first.post_id end -Derrick Spell "Perl's grammar can not be reduced to BNF. The work of parsing perl is distributed between yacc, the lexer, smoke and mirrors.'' -Chaim Frenkel ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Bus Error on OpenBase Adapter
Good Evening, The OpenBaseAdapter is almost ready to be submitted as a patch. It passes all the tests except for 9 expected failures. There is a bug in the way OpenBase processes limit/offset clauses. I have a ticket number on this and it should be fixed in the next release of OpenBase. However... The adapter only passes all the tests if I run them one at a time. I have a perl script (hey, you do what you know, right?) that executes each _test.rb file in it's own ruby process. If I use rake or the all.sh file, then the process will eventually crash with a Bus Error. I'm thinking there may be a memory leak in the Ruby-OpenBase library I'm using, but I'm not sure. I can't tell for sure which test file is crashing, although i've had crashes at different points in the testing progress. Usually it crashes at the same line of my adapter: col_infos.each_index do |index| where col_infos is an array of OpenBaseColumnInfo objects (a class defined in the Ruby-OpenBase library). However, I have occasionally seen crashes (and memory warnings) in other files which seem to be part of the ruby language, i.e. outside of rails completely. Anyway, since I've only been programming in Ruby for 2 weeks, I figured I'd throw this out and see if the experts have any insight to share. -Derrick "Perl's grammar can not be reduced to BNF. The work of parsing perl is distributed between yacc, the lexer, smoke and mirrors.'' -Chaim Frenkel ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] anyone in a committing mood?
On Feb 10, 2006, at 2:49 PM, David Heinemeier Hansson wrote:If it would help I can bundle them all up into a single patch, just letme know. It would. Please do roll them all up into 1 patch and get a fewOracle'ers to try that out. If you could get them to comment on thisnew ticket with "+1 works for me", then that'd be great. Thanks!--Would a similar approach be helpful for the new OpenBase adapter (ticket #3538)? I'm guessing it hasn't even been looked at because of the overhead in getting your system ready to test it...install new bindings...install openbase...I haven't yet looked into making this a plugin so that it can be tested with ease. Is such a plugin possible? If so, can someone point me to some docs to get me started on making one? Derrick Spell Webmaster / Programmer Suran Systems, Inc. ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Default <%= to use the h (html safe) method.
To be honest, it took me up until about a few weeks ago to come
across a
posting from someone in the Rails community why <%=h is needed to
secure the
output of the user input. I have been developing with rails for
some time
now, and I know a few things about XSS, yet still, while I was
shifting my
paradigm to Rails, I had simply forgot about encoding my HTML
output. The
apps I have written are not blogware, or open to the public so this
wasn't a
major concern of mine, but it brought up a good point. At what
point do we
say, OK, I need to secure my application now.
I find this hard to believe. I heard about escaping with <%=h on my
first day on Rails. Also, I love how escaping has become synonymous
with "secure", when the issue of security goes far beyond html
escaping. For instance, your next point...
Another example to highlight is the :conditions on things such as
model.find. This should always be encoded, and you should have to
override
the default to allow direct data insertion.
That said, when finding all records such as this:
Model.find(:all, :conditions => 'this = "' + params[:xss] + '"')
Should not even be allowed to happen. One method I had found, maybe
a month
after getting into Rails, was a post by Robby mentioning how to use
hash
marks, like so:
Model.find(:all, :conditions => ['this = :this', {:this => params
[:xss]}])
Now, from what I gather that is the secure way of writing a
condition, yet
TONS of people I can guarantee have no idea about this, or even the
simpler
method without the named using the sprintf method. Either way,
security
should be default, and you should have to break off the Rails path
to choose
to open up security holes in your application.
- Nb
How could anybody go through the present documentation on rails and
not come across this? Have you even read AWDWR? I can't even count
how many times this has been presented to me in my reading on rails.
Not to mention, if it hadn't been presented to me, I would have gone
looking for it. It should be common knowledge for any database
developer, whether web related or not, that variables in SQL
statements should be bound. If this syntax hadn't been so accessible
I would have said, "Ok, so how do I bind variables in Ruby...there
must be something akin to my old friend the '?' character from the
Perl DBI."
Furthermore, how do you prevent someone from simply concatenating the
variable into the string? This would require some sort of pre-
compile to detect the presence of the concatenation operator in the
parameter string...and oh yeah, we would need to make sure they
didn't use #{} either. The find method can't know if the string was
written explicitly or pieced together from several variables. This
is a compilation issue...talk about a performance hit!
There are always going to be newbies, and the newbies need
information about how to write "safe" code. Therefore, we must keep
writing it. However, if we attempt to restrict the language in such
a way as to make it impossible to write sloppy code, we'll end up
with nothing more than AppleScript for the web...or worse
yet...HyperCard! However, anybody with the 2-3 years experience it
usually takes to get a job without a supervisor breathing down your
neck while you program will already know this stuff. If they haven't
learned it by now, they're dangerous and should get out of the industry.
Don't tie my hands. If you're scared of your own code, write an
acts_as_diffident plugin. If this email sounds harsh, you can blame
it on the fact that I'm hungry, tired, or both... or perhaps I'm just
right... who knows?
-Derrick Spell
"Perl's grammar can not be reduced to BNF.
The work of parsing perl is distributed between
yacc, the lexer, smoke and mirrors.''
-Chaim Frenkel
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Database Adapter Plugin
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... In looking into what constitutes a plugin, I felt even more lazy and stupid. All i needed to do was put my openbase_adapter.rb into a vendor/plugins/openbase/lib folder. A single line init.rb file to require the adapter and voila! Instant OpenBase! Ruby truly is a beautiful language. The whole process brought a tear to my eye. But then...Disaster! Still no adapter! Not wanting to admit defeat, nor to bother the core list with a trivial question during the big 1.1 push, I delved further into the core than I had before. And gentlemen, might I congratulate you on a rather beautiful code base. Very clean. In just a few minutes I had tracked it down. The initializer attempts to initialize_database before it attempts to load_plugins. Of course, without a database adapter the initializer ultimately raises an AdapterNotFound error and exits without ever loading my lovely new plugin. I said to myself, "Self, you need to get your plugin loaded earlier". And there it was...the environment. I added a single line to environment.rb, just above the call to Rails::Initializer.run: Rails::Initializer.run(:load_plugins) Woohoo! OpenBase has been found! But now it seems that I've violated the very spirit of the plugin. A plugin shouldn't require a developer to do anything more than drop the plugin into the vendor/plugins directory, right? With my limited exposure to the core, I knew no other answer. Realizing that I'm going to fail my compilers course if I don't get back to doing my homework, I decided I would ask the experts. Gentlemen (and ladies, perhaps?), what could I have done better? -Derrick Spell ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Database Adapter Plugin
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. I just ran the test suite against a fresh update of the trunk. After adding a couple of new test tables, there are still 0 errors, but the 9 known failures have increased to 19. There are just two causes: * LIMIT and OFFSET are broken in OpenBase. And actually, the tests expecting 0 results when using LIMIT 0 will always fail. The guys at OpenBase feel that LIMIT 0 should be equivalent to not having a limit at all. That way you can be a little sloppy with SQL generation and always include the limit statement even when the user doesn't specify a limit. * GROUP BY works a little strange in OpenBase. Some of the new tests for the :group option are failing. I may be able to overcome this if I look into it a little closer. Of course, these failures are due to idiosyncrasies in OpenBase SQL that most OB guys are going to be expecting. They know they won't get the right values with :offset, and they tend to write their group by clauses in OB friendly ways. I have also fixed a couple minor bugs that I've come across in using the adapter for the last month. So, in short ... yes, I think version 3 of the patch at ticket #3538 is "ready enough". I'm positive that it could stand some refactoring. This adapter was the first thing I ever wrote in Ruby. Yeah, I know, most people write a hello world program, or go through the blog screencast or something. I like the immersion approach. Anyway, I could have never gotten rails past my boss if it didn't work with his favorite database server. The adapter is 345 riveting lines if anyone needs some bedtime reading... -Derrick Spell ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] please apply patch to fix ActiveRecord
Smells a bit like something that's been cooking in the Rails Recipes kitchen.-Derrick SpellOn Mar 31, 2006, at 3:10 PM, Steve Longdo wrote:good stuff!http://en.wikipedia.org/wiki/Continuous_integration http://docs.codehaus.org/display/DAMAGECONTROL/Continuous+Integration+Server+Feature+Matrix-SteveOn 3/31/06, Michael Schoen < [EMAIL PROTECTED]> wrote:Blair Zajac wrote:> You could have another list with a Reply-To this list and when the build > breaks, additionally cc the committer that broke the build.Seems like that might require running the test after each individualcommit, in order to be certain which commit break the build.___ Rails-core mailing listRails-core@lists.rubyonrails.orghttp://lists.rubyonrails.org/mailman/listinfo/rails-core ___Rails-core mailing listRails-core@lists.rubyonrails.orghttp://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] oracle boolean support
On Apr 26, 2006, at 12:24 PM, Corey Donohoe wrote: I currently have to support both postgres and oracle for work. I'd like to use booleans but I ran into a wall when I found oracle didn't support them. The fix was really small and I adopted the convention of NUMERIC(1) being boolean. It also uses a similar approach as the mysql driver by allowing it to be disabled if the app doesn't want to leverage booleans. I bounced the idea off of Michael Schoen but he thinks people might be using NUMERIC(1) for values between 0-9. I can see his point but I think for most the most part people would want to have this option available for consistencies sake. If anyone has any input on this I'd greatly appreciate it, tests/patch/etc at http://dev.rubyonrails.org/ticket/4811 I think it's a good idea. You could always provide a flag to turn off the boolean emulation (MySQL adapter does this). -Derrick Spell ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Ticket 5176: Email Address Change
Hey guys, This was hardly worth a patch, but I did one anyway. I just changed jobs, and need to change my email address in the OpenBase adapter documentation. When somebody gets bored, here it is... http://dev.rubyonrails.org/ticket/5176 -Derrick Spell ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Ticket 5176: Email Address Change
This was hardly worth a patch, but I did one anyway. I just changed jobs, and need to change my email address in the OpenBase adapter documentation. When somebody gets bored, here it is... http://dev.rubyonrails.org/ticket/5176 Done. Thanks. (Not particularly bored...) ;) marcel Such service! Thanks, Marcel. -Derrick ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
