in reply to Re^11: threads::shared seems to kill performance (Workaround).
in thread threads::shared seems to kill performance

Actually, those URI question mark query parameters don't seem to be getting across - they're just considered part of the filename for whatever reason: 

    CONNECT=> 'dbi:SQLite:dbname=file:mysqlite.db?cache=shared'
19456 Jul 25 00:32 file:mysqlite.db?cache=shared

    CONNECT=> 'dbi:SQLite:dbname=mysqlite.db?cache=shared'
19456 Jul 25 00:34 mysqlite.db?cache=shared

[download]
I'm getting exactly the same results on OS X 10.8 and Ubuntu 13.04. I even tried updating DBI and DBD::SQLite to the latest versions, but with no effect. I'm using the exact code you posted today and I'm just changing the CONNECT constant as shown above.

I must be doing something very stupid I just can't find what that is :-(

Replies are listed 'Best First'.
Re^13: threads::shared seems to kill performance (Workaround).
by BrowserUk (Patriarch) on Jul 24, 2013 at 22:54 UTC

    Did you read the "backwards compatibility" section of http://www.sqlite.org/uri.html?

    Now I've understood the reason behind the straems thing; it seems likely that the DBD::Sqlite(2) package is not configuring the compile to allow the URI-forms.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      After recompiling the SQLite used by DBD::SQLite with SQLITE_USE_URI, it works flawlessly!

      Btw I did read that document about 17 times, but I always skipped the Backwards compatibility section as not important and focused on the Format instead. And then banged my head against the wall wondering why it doesn't work :-(

      Just one last thing - do you know if I can somehow use any of those other 2 ways to enable this via DBD::SQLite? I want to avoid having to recompile SQLite on every machine on which I use this. They seem to be meant primarily for the C interface, but I wonder if there's some way to invoke them from Perl as well:

      • The sqlite3_config(SQLITE_CONFIG_URI, 1); configuration option is set at application start-time.
      • The SQLITE_OPEN_URI bit is OR-ed in with the set bits passed in as the 3rd parameter to the sqlite3_open_v2() interface.

[reply]
        After recompiling the SQLite used by DBD::SQLite with SQLITE_USE_URI, it works flawlessly!

        That's great news. I'll get around to trying it here sometime soon.

        Just one last thing - do you know if I can somehow use any of those other 2 ways to enable this via DBD::SQLite?

        I don't know. My assumption is that unless it is enabled at compile time, it won't work.

        I guess if passing the appropriate options/parameters can override the compile-time setting (at the C interface), then it would be possible to pass-through an option from Perl to the XS code to do the same.

        But either way would require the DBD::Sqlite author to patch his code; and adding the compile-time define seems simpler to me.

        If you have time and inclination you might try emailing the author (of DBD::Sqlite(2)) and make your case for enabling this by default.

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom