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
I think in your particular case it''s perfectly fine to require the developer to add a special line - after all, this is a piece of code that will (hopefully) become a part of the core. It''s just a fact of the way the plugin system works at the moment that some aspects of of the framework cannot be loaded in the normal flow of things. Just make sure the documentation is ultra clear... - james On 2/28/06, Derrick Spell <derrickspell@cdmplus.com> 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... > > 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 >-- * J * ~
-----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-----
>> 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
On Feb 28, 2006, at 8:04 PM, Derrick Spell wrote:> > * 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.Sybase is similar. To fix this, I had to distinguish between limit- not-set and limit-explicitly-set-to-zero. Check out my sybase patch for ideas (#3765). You can use the horrific "select ... where 1=2" hack to return zero results when :limit = 0. Not the most intellectually rewarding, but it is effective and the simplest solution I found. I ended up using a temp table to handle :offset, since Sybase has (AFAIK) no support for that either. Hopefully that''ll work for OpenBase too. My normal_select?() method determines whether or not to use the temp table select, depending on the values of :limit and :offset. John -- John R. Sheets http://umber.sourceforge.net http://writersforge.sourceforge.net