ahn and sequel or other non ActiveRecord ORM

[ik]

Hello,

Does AHN support non activerecord ORM by default (I mean like adhearsion-sequel for example) ?

If not, will there be any issues for me to use other ORM ?

Thanks,

Ido

[Andrius Kairiukstis]

Would be nice to get an official answer, but I never had any issues with both Sequel and Mondoid working standalone, same with Activerecord – working standalone (my AR methods had a function named voice, i.e.

Company.find_by_name("Acme, Inc.").andand.voice(params), same as mongoid

And concurrency is only one major AR issue, hope someday it will be fixed by developers. Access lockers helps with that.

Regards,

Andrius Kairiukstis

e-mail: k...@andrius.mobi, blog: http://andrius.mobi

contacts: http://about.me/andrius.kairiukstis

telephone numbers:

      (ES) +34 652 299 183,

      (UK) +44 20 3603 3803,

      (LT) +370 5 203 0095

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adhearsion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Le Cuirot]

On Sun, 19 May 2013 09:31:19 +0200
Andrius Kairiukstis <and...@kairiukstis.com> wrote:

> And concurrency is only one major AR issue, hope someday it will be
> fixed by developers. Access lockers helps with that.

Opinions differ on this but I believe it is already resolved in the
upcoming Rails 4. There was an issue where you had to allocate an
unreasonably large pool size to avoid long delays and timeouts while
waiting for a connection. This was because the queue was not fair but
essentially random. I have backported this fix to 3.2.13 if you're
interested.

You still have to wrap all database activity in
ActiveRecord::Base.connection_pool.with_connection blocks though. I'm
not sure what Sequel does but I don't find this unreasonable. Without
this, the connection either has to remain open for the duration of the
thread (which could be very long) or some arbitrary timeout must be
used. I'd rather say exactly when my database connections are needed.

Regards,
James

[Andrius Kairiukstis]

Please share, especially if you have that code on github

Regards,

Andrius Kairiukstis

e-mail: k...@andrius.mobi, blog: http://andrius.mobi

contacts: http://about.me/andrius.kairiukstis

telephone numbers:

      (ES) +34 652 299 183,

      (UK) +44 20 3603 3803,

      (LT) +370 5 203 0095

[James Le Cuirot]

> On Sun, May 19, 2013 at 12:25 PM, James Le Cuirot
> <ch...@aura-online.co.uk>wrote:
>
> > On Sun, 19 May 2013 09:31:19 +0200
> > Andrius Kairiukstis <and...@kairiukstis.com> wrote:
> >
> > > And concurrency is only one major AR issue, hope someday it will
> > > be fixed by developers. Access lockers helps with that.
> >
> > Opinions differ on this but I believe it is already resolved in the
> > upcoming Rails 4. There was an issue where you had to allocate an
> > unreasonably large pool size to avoid long delays and timeouts while
> > waiting for a connection. This was because the queue was not fair
> > but essentially random. I have backported this fix to 3.2.13 if
> > you're interested.
> >
> > You still have to wrap all database activity in
> > ActiveRecord::Base.connection_pool.with_connection blocks though.
> > I'm not sure what Sequel does but I don't find this unreasonable.
> > Without this, the connection either has to remain open for the
> > duration of the thread (which could be very long) or some arbitrary
> > timeout must be used. I'd rather say exactly when my database
> > connections are needed.
> >
> > Regards,
> > James
> >

On Sun, 19 May 2013 12:44:06 +0200
Andrius Kairiukstis <and...@kairiukstis.com> wrote:

> Please share, especially if you have that code on github
>
> Regards,
>
> Andrius Kairiukstis

Please see the attached patch. The original work comes from:
https://github.com/rails/rails/pull/7675

I just brought it up to date. It wasn't merged for Rails 3 because it
breaks some PostgreSQL tests in a manner that they weren't prepared to
investigate. I do use PostgreSQL so I haven't used this patch in
production and may just wait for Rails 4.

Regards,
James

[ik]

ActiveRecord is a pain. They finally implemented the pool properly, but it's too little too late imho.

It has a lot of issues in the way they implement stuff. For example SQLi for things they created in runtime, that render ORM useless in it's idea.

Sequel writes where are the places you must understand that may create SQLi, and teaches you to work with named parameters everywhere, while AR does not do that.

 

Regards,
James

[Ben Langfeld]

Or you check the connection out of the pool for every query, and just implement a fast pool. This is what Sequel does. This is equivalent to implicit use of #with_connection. This makes it safe. By default Sequel does not hold a connection out of the pool for any longer than necessary.

Of course, this approach is less efficient in a case where you have a large number of queries in sequence, but Sequel has you covered here too. Sequel::ConnectionPool#hold is reentrant, so you just do this and stop worrying:

DB.pool.hold do

  query1....

  query2....

  ....

end

So what you have here is all of the benefits of AR #with_connection, and none of the downsides. The only thing Sequel doesn't currently allow (the required methods are private) is tagging a connection to a thread permanently. AR has proven that this approach is dangerous and I doubt there are many cases where it provides improved performance.

What Sequel does is optimise for safety in the majority of cases where huge performance problems could be introduced by accident (a thread holding a connection from the pool when it's not being used) rather than optimising for the fewest checkouts per thread, which is a narrow performance edge-case of which the people who need it will already be aware.

The approach being taken for ActiveRecord indicates one thing: the core team do not care about AR being useful outside of Rails. IMO they should state this up-front.

 

Regards,
James

[Ben Langfeld]

There is a plugin prepared by Ben Klang for Sequel support here: https://github.com/bklang/sequella

AFAIK it's unreleased, so you'll have to work with it from git for now. If someone pestered Ben for a release, I'm sure it'd get cleaned up :)

Regards,
Ben Langfeld

--

[ik]

On Sun, May 19, 2013 at 6:05 PM, Ben Langfeld <b...@langfeld.co.uk> wrote:

There is a plugin prepared by Ben Klang for Sequel support here: https://github.com/bklang/sequella

AFAIK it's unreleased, so you'll have to work with it from git for now. If someone pestered Ben for a release, I'm sure it'd get cleaned up :)

Thanks, that's looks nice :)

[Ben Klang]

For the record, I released Sequella 1.0 this morning:

http://rubygems.org/gems/sequella

/BAK/

-- 

Ben Klang

Principal/Technology Strategist, Mojo Lingo

bkl...@mojolingo.com

+1.404.475.4841

Mojo Lingo -- Voice applications that work like magic

http://mojolingo.com

Twitter: @MojoLingo

[ik]

On Mon, May 20, 2013 at 6:12 PM, Ben Klang <bkl...@mojolingo.com> wrote:

For the record, I released Sequella 1.0 this morning:

http://rubygems.org/gems/sequella

thank you for it :)