#448 ✓not-applicable
Nolan Darilek

DataMapper.setup should pass non-standard options to low-level adapters

Reported by Nolan Darilek | July 7th, 2008 @ 04:22 PM

I have an application using DM which will initially be tied exclusively to SQLite3. I need to load a SQLite3 extension, but in order to do this, I must first call sqlite3_load_extension(1) in native code. There is currently no way (visible to me, at least) of accessing low-level database connections, which would probably be a good architectural addition for later on, but for the moment it'd be great if DataMapper.setup passed options it didn't understand from its options hash to the low-level adapter. So if I could do something like:

DataMapper.setup(:default, :database => "atlas.dat", :adapter => :sqlite3, :sqlite3_load_extension => true)

then :sqlite3_load_extension would be passed to the adapter to use or ignore as it wished. I could then check for its presence in the native DO code and call the necessary C code such that I can then call "SELECT load_extension(...)" using repository.execute.

Comments and changes to this ticket

  • Jonathan Stott (namelessjon)

    Jonathan Stott (namelessjon) November 30th, 2008 @ 08:24 AM

    • Tag changed from adapter, sqlite3 to adapter, do_sqlite3, suggestion
    • State changed from “new” to “open”
    • Assigned user cleared.
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) December 1st, 2008 @ 01:04 PM

    • State changed from “open” to “hold”

    Nolan, have you tested this? DataMapper.setup should've always been passing any unhandled options down to the lower level DO driver.

  • Michael Klishin (antares)
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 16th, 2009 @ 04:16 PM

    • Assigned user set to “Dan Kubb (dkubb)”
    • State changed from “hold” to “resolved”
    • Milestone set to 0.10.0

    I can also confirm this is the case. Marking this ticket as resolved.

  • Adam Luter

    Adam Luter August 10th, 2009 @ 02:05 PM

    Am I missing something? The adapter may end up getting the option, but it doesn't do anything with it. The result is you still can't load extensions into a sqlite3 adapter. In fact, as far as I can tell the problem lies in DataObjects::Sqlite3 which fails to provide this function in it's API. (A binding to sqlite3_enable_load_extension).

  • Adam Luter

    Adam Luter August 11th, 2009 @ 12:21 PM

    I've written a patch to DataObjects that is a stab at making extension loading work for Sqlite3:

    http://github.com/gryn/do/commit/f4f00d6634c7a869ab54aae19079c8d39f...

    However, I welcome advice on how to avoid the class variable extensions I have added which sets which extensions to load on all new connections.

    Rather, I would like to only use the load_extension instance method on a connection to load extensions on new connections.

    Unfortunately, I could not unravel DataMapper well enough to figure out how to start at Datamapper.setup and end up with a call to load_extensions on any created connection.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) August 12th, 2009 @ 11:24 AM

    • Assigned user changed from “Dan Kubb (dkubb)” to “Dirkjan Bussink”
    • State changed from “resolved” to “unconfirmed”
    • Milestone cleared.

    @Dirkjan: I'm not sure how you want to handle extensions to DataObjects, so I am assigning this to you to review and comment on.

  • Dirkjan Bussink

    Dirkjan Bussink August 12th, 2009 @ 02:24 PM

    How common is this concept of extensions for different database drivers? That's for me the main question. Is this useful for other RDBMS like MySQL or PostgreSQL and what is needed on those platforms? DataObjects provides a general API, so I'm hesitant to added all kinds of specific functionality.

    Another this is that this patch seems to be against the master branch, which is only used for maintenance and not new functionality. All new stuff is added to the next branch, when a release is pushed out, this is merged back to master and the development for a new version starts off from there.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) September 10th, 2009 @ 03:47 PM

    • State changed from “unconfirmed” to “not-applicable”

    @Dirkjan: I don't think this concept maps cleanly to any other DBs. I'd suggest this functionality be added in as a separate plugin and not part of DO itself.

    I am closing this ticket for now due to inactivity. I will reopen if further discussion continues.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket

Pages