If you're hand-writing complex queries that for one reason or another rely on features that are only available to one SGDB in particular, then here's part of the cost for doing so.
I wouldn't say it means the idea of in-memory databases is a bad one unless you're leaning a lot of your logic against the DB as opposed to relying on a ORM. If you don't, then you can have a production system running on PostgreSQL, in-memory SQLite databases for tests, and so on. On Tue, Mar 23, 2010 at 11:21 AM, Ben Schwarz <ben.schw...@gmail.com> wrote: > Other option may be to still use the same database engine but have a > transparent caching layer in between. > I really wanted to get people to step back away from the problem with a > solution and back to the problem itself. > > > On 23/03/2010, at 10:48 AM, Simon Russell wrote: > >> Hi there, my first post. >> >> The Mysql in-memory database is pretty basic; sort of like MyISAM, but >> with even fewer features. To me it sort of defeats most of the >> purposes of testing to test against a completely different database >> engine (that doesn't even try to support the same features). I think >> some time ago (somewhere else) there was mention of another database >> engine that could do in-memory stuff, I can't remember what it is. >> >> On Tue, Mar 23, 2010 at 10:44, David Lee <deathtoallfanat...@gmail.com> >> wrote: >>> Last time i benchmarked it vs postgresql tuned for testing (no fsync, etc) >>> PG came out on top on the suite i was running by a reasonable margin. If >>> memory serves ... i think it was partly because sqlite is so crippled (no >>> subselects, etc) it had to run (sometimes vastly) more queries to do the >>> equivalent work. >>> That was a couple years ago - if anyone has better datapoints throw them in >>> ... >>> Interesting to know mysql has the same feature, as it's less handicapped >>> than sqlite. Maybe I'll try it out - I'm certain few of my current projects >>> would work w/ sqlite, but should on mysql. >>> >>> On Tue, Mar 23, 2010 at 10:10 AM, Ben Schwarz <ben.schw...@gmail.com> wrote: >>>> >>>> Has anyone in this thread tried using an in-memory database rather than >>>> looking at using SSD or re-inventing machinist? >>>> Both sqlite and mysql have in-memory databases or tables. I'm sure that >>>> other rdbms implementations would also. >>>> >>>> I've used sqlite :memory: in the past when using datamapper and found it >>>> to greatly increase the runtime speed for the testing environment. >>>> Surely this would prove greater gains than re-thinking machinst? >>>> >>>> Of course, I don't want to get in the way of your hacking project. >>>> >>>> On 23/03/2010, at 10:06 AM, Pete Yandell wrote: >>>> >>>>> I like having an empty database for each test too, but I'd be more >>>>> than willing to trade that for faster tests. >>>>> >>>>> If it's not solved before then, anyone fancy spending some time at >>>>> Railscamp working on making this happen? >>>>> >>>>> - Pete >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Ruby or Rails Oceania" group. >>>>> To post to this group, send email to rails-ocea...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> rails-oceania+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/rails-oceania?hl=en. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Ruby or Rails Oceania" group. >>>> To post to this group, send email to rails-ocea...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rails-oceania+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/rails-oceania?hl=en. >>>> >>> >>> >>> >>> -- >>> cheers, >>> David Lee >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ruby or Rails Oceania" group. >>> To post to this group, send email to rails-ocea...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rails-oceania+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/rails-oceania?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-ocea...@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-ocea...@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- http://crazyhollywood.org -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
