Hi,
I''ve been playing around with using DBI instead of ActiveRecord
''cause
I just love to beat myself up! ;) Is this an okay way to do this, or
is there any other more creative ways?
require ''dbi''
module MyApp:Models
class DB
def self.dbh
DBI.connect(''DBI:Mysql:dbname'',
''username'', ''password'')
end
end
class Category < DB
def self.find
dbh.select_all(''SELECT * FROM myapp_categories'')
end
def self.find_by_id(id)
dbh.select_all(''SELECT * FROM myapp_categories WHERE id =
?'', id)
end
end
end
module MyApp:Controllers
class Index < R ''/''
def get
@categories = Category.find
render :index
end
end
end
On 1/26/07, James <jamesd.earl at gmail.com> wrote:> Hi, > > I''ve been playing around with using DBI instead of ActiveRecord ''cause > I just love to beat myself up! ;) Is this an okay way to do this, or > is there any other more creative ways?The code looks like it''ll *work*, but you''re not going to get much of a performance boost over regular ActiveRecord -- esp. since you reconnect to the database for each query! Try this: --- class DB def self.dbh @dbh ||= DBI.connect(''DBI:Mysql:dbname'', ''username'', ''password'') end end --- That way, your connection will only be established once per model class, and will stay open between requests. Alternately, you could set @@dbh instead of @dbh, which would open just one connection for all your model classes, but you might have problems handling multiple simultaneous requests through a single active database handle. -Lennon
On 1/26/07, Lennon Day-Reynolds <rcoder at gmail.com> wrote:> That way, your connection will only be established once per model > class, and will stay open between requests. Alternately, you could set > @@dbh instead of @dbh, which would open just one connection for all > your model classes, but you might have problems handling multiple > simultaneous requests through a single active database handle.Thanks, I learned something new! Would it be okay to use a constant DBH to represent the database handle? James
Maybe, but does that benefit you? Constants aren''t allowed to be set more than once (when you first define them), so using one as a DB connection might potentially cause problems if you ever reset it. It''s also "unfashionable" in Ruby land to use constants over instance variables for this work. -- Eric On 1/26/07, James <jamesd.earl at gmail.com> wrote:> On 1/26/07, Lennon Day-Reynolds <rcoder at gmail.com> wrote: > > That way, your connection will only be established once per model > > class, and will stay open between requests. Alternately, you could set > > @@dbh instead of @dbh, which would open just one connection for all > > your model classes, but you might have problems handling multiple > > simultaneous requests through a single active database handle. > > Thanks, I learned something new! Would it be okay to use a constant > DBH to represent the database handle? > > James > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
Thanks Eric, using a constant wouldn''t really benefit me. I was just kinda curious as that''s what I originally tried using, and while it worked I was kinda thinking to myself that "this probably isn''t a good thing." I''ll probably end up using ActiveRecord. I just get caught up sometimes in the memory game, and hate seeing my memory usage sky rocket as I pull large results. But if I have the memory, why not use it to my advantage! James On 1/26/07, Eric Mill <kprojection at gmail.com> wrote:> Maybe, but does that benefit you? Constants aren''t allowed to be set > more than once (when you first define them), so using one as a DB > connection might potentially cause problems if you ever reset it. > It''s also "unfashionable" in Ruby land to use constants over instance > variables for this work. > > -- Eric
> I''ll probably end up using ActiveRecord. I just get caught up > sometimes in the memory game, and hate seeing my memory usage sky > rocket as I pull large results. But if I have the memory, why not use > it to my advantage!If the situation is something like having an application that only requires only one or two SQL queries, then why not skip ActiveRecord? I''m interested in how one can skip the database altogether, though. This seems like something that must have come up here before? But personally, I threw together a little number I like to call DirectoryModel[1] that just keeps track of the files in a directory for a (very) small comic-strip app[2]. I bet it needs some work! I wanted to say a thing or two about that application, actually. I felt it was not a good idea to have Camping keeping track of everything, like it would be a bad idea to have it serving html pages and comic strip images, because lighttpd can do that better. What I do instead is have Camping act as a sort of primitive stand-in for WebDAV or something and post comic strip images via curl. When my app gets a PUT request, it saves the image I''ve sent it (which is just speech bubbles), generates the full strip image, and generates or regenerates any html files which need it. Putting this sort of way of interacting (basically, no posting html forms over http for admin stuff) with the server to use in apps interests me a fair bit, and I was going to post more about it but I fear the post I was going to make became sort of off-topic. To me this seems like an exciting and appropriate use for Camping, though! -- Michael Daines [1] http://pastie.caboo.se/36319 (sorry, no public svn repository) [2] http://penguins.mdaines.com
On 1/27/07, James <jamesd.earl at gmail.com> wrote:> [...] > I''ll probably end up using ActiveRecord. I just get caught up > sometimes in the memory game, and hate seeing my memory usage sky > rocket as I pull large results. But if I have the memory, why not use > it to my advantage!This is one of the biggest issues with ActiveRecord, in my opinion: i.e., having to instantiate all your model objects before iterating over them. It''s not just a question of RAM -- the load on the database server and network traffic are significant, too. Using DBI, you should be able to do more intelligent iteration over result sets -- esp. if you pass actual database cursor handles from your models to controller, instead of pre-fetching everything. -Lennon
On 1/28/07, Michael Daines <michael.daines at gmail.com> wrote:> I''m interested in how one can skip the database altogether, though. > This seems like something that must have come up here before? But > personally, I threw together a little number I like to call > DirectoryModel[1] that just keeps track of the files in a directory > for a (very) small comic-strip app[2]. I bet it needs some work!I tend to use YAML::Store as a sort of poor-man''s database for simple apps like that. There''s also a module called ''fsdb'' I used for a couple of projects which, IIRC, uses a one-file-per-object model for persistent storage. Running a full-featured client/server SQL database engine for applications that have only a handful of users is often overkill. -Lennon
> Running a full-featured client/server SQL database engine for > applications that have only a handful of users is often overkill.Agreed -- I think this is one of the reasons why pushes SQLite so much and makes it the default DB engine for Camping. I''ve started hearing things about Kirbybase (http://www.netpromi.com/kirbybase_ruby.html) though. It''s a non-SQL storage engine, uses pleasant Ruby syntax and blocks, and stores data in flat, easy to edit files. Has anyone used it? Is it any better than using Yaml? -- Eric On 1/28/07, Lennon Day-Reynolds <rcoder at gmail.com> wrote:> On 1/28/07, Michael Daines <michael.daines at gmail.com> wrote: > > I''m interested in how one can skip the database altogether, though. > > This seems like something that must have come up here before? But > > personally, I threw together a little number I like to call > > DirectoryModel[1] that just keeps track of the files in a directory > > for a (very) small comic-strip app[2]. I bet it needs some work! > > I tend to use YAML::Store as a sort of poor-man''s database for simple > apps like that. There''s also a module called ''fsdb'' I used for a > couple of projects which, IIRC, uses a one-file-per-object model for > persistent storage. > > > -Lennon > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >
> I tend to use YAML::Store as a sort of poor-man''s database for simple > apps like that. There''s also a module called ''fsdb'' I used for a > couple of projects which, IIRC, uses a one-file-per-object model for > persistent storage.Wish I''d taken the time to look around... I have certainly implemented a poor copy of YAML::Store before!
On 1/29/07, Eric Mill <kprojection at gmail.com> wrote:> > Running a full-featured client/server SQL database engine for > > applications that have only a handful of users is often overkill. > > Agreed -- I think this is one of the reasons why pushes SQLite so much > and makes it the default DB engine for Camping. I''ve started hearing > things about Kirbybase (http://www.netpromi.com/kirbybase_ruby.html) > though. It''s a non-SQL storage engine, uses pleasant Ruby syntax and > blocks, and stores data in flat, easy to edit files. Has anyone used > it? Is it any better than using Yaml? > > -- Eric >Kirbybase is mind-blowingly awesome. It''s better than yaml for doing DB like things because when you update a record it actually updates the record in-place in the file (if it can) instead of having to regenerate the entire file. Also, it has slightly more evolved ''select'' like methods and things. (: I''ve used it in several of my own projects (stuff that was done before camping existed) to great effect. The fact that it''s pure Ruby is just beautiful. In my uber-humble opinion, distributing gem wrappers for C stuff (sqlite for example) is still a bit tougher to do in a heavily cross-platform situation. Recently I''ve been using sqlite since I''ve been working on slightly larger apps that target a single platform ... IIS :( *barf* ... But I''ve found a nice combination of ruby-web.exe, sqlite3, and ArrayFields that keeps me pretty productive. I keep telling myself that I''m going to try to get camping running on IIS, but I don''t know really where to start. I guess I could use one of the post-amble CGI versions and run it using Ruby as an ISAPI filter, but I don''t know much about active record. I''m pretty sure that the ISAPI filter method would start a new copy of the interpreter for each page request which I think is a recipe for disaster with ActiveRecord. (?) Sorry to get off topic. :P At one point someone was working on an ActiveRecord - Kirbybase bridge called "Akbar" ... But I think it rusted from disuse... Kirbybase/Akbar/Camping sounds like fun though... heh, -Harold