Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re: DBD::Sqlite queries slow - and gives wrong results

by sundialsvc4 (Abbot)
on Dec 11, 2017 at 22:57 UTC ( #1205311=note: print w/replies, xml ) Need Help??


in reply to DBD::Sqlite queries slow - and gives wrong results

This node falls below the community's threshold of quality. You may see it by logging in.
  • Comment on Re: DBD::Sqlite queries slow - and gives wrong results

Replies are listed 'Best First'.
Re^2: DBD::Sqlite queries slow - and gives wrong results
by Your Mother (Archbishop) on Dec 12, 2017 at 05:31 UTC

    You side-stepped the OP's question, predictably. NetWallah managed to make an interesting and helpful technical suggestion even without having an answer to the problem.

    Could you please cite the SQLite documentation which suggests the wisdom of using transactions for SELECT statements? Barring that, please provide benchmark code supporting your position that it is a best practice. COGTFO®

Re^2: DBD::Sqlite queries slow - and gives wrong results
by herveus (Parson) on Dec 12, 2017 at 18:45 UTC
    Howdy!

    First, "citation needed", because you are making wild claims with no supporting evidence.

    A select requires a SHARED lock, and that is done via a transaction. If you have multiple select statements that you want to ensure all read the same set of data, wrap them in a transaction. Also to reduce locking overhead.

    What is the actual relevance of the lack of a "SQL server"? What do you mean by that? The SQLite engine does its thing just as any other RDBMS engine does, but not as a persistent external process. That has nothing to do with all of the italicized and scare-quoted phrases your imprecation is larded with.

    And, on top of that, what relevance does your prescription have to the actual question at hand? You rail about something without explaining how it matters.

    So, your closing remark is, on its face, incorrect, as it appears that no actual help was provided. Please stop.

    yours,
    Michael
Re^2: DBD::Sqlite queries slow - and gives wrong results - HEADWHACK
by erix (Prior) on Dec 13, 2017 at 11:20 UTC

    Short-Answer: Do This Now: “Bracket all of your SQLite calls, whether(!) read or write, in transactions.”

    He's already using transactions; see the connection parameter 'AutoCommit=>0' or TIAS:

    $ perl -MDBI -e 'my$d=DBI->connect("dbi:SQLite:dbname=x.db","","",{Aut +oCommit=>0}); $d->begin_work or die "ah, of course! *HEADWHACK*\n"' DBD::SQLite::db begin_work failed: Already in a transaction at -e line + 1. ah, of course! *HEADWACK*

Re^2: DBD::Sqlite queries slow - and gives wrong results
by marto (Cardinal) on Dec 12, 2017 at 10:42 UTC

    “Personally been there. Personally whacked my head against that.”

    I wonder if this could be contributing to the nonsense continually pollute this site with?

Re^2: DBD::Sqlite queries slow - and gives wrong results
by eyepopslikeamosquito (Bishop) on Dec 13, 2017 at 22:09 UTC

    Short-Answer:   Do This Now:  

      Pick up all “SQL manuals” on your “desk” ... whether small or big(!)
      Personally whack your head against them

    HTH™ ...

Re^2: DBD::Sqlite queries slow - and gives wrong results
by Anonymous Monk on Dec 11, 2017 at 23:17 UTC
    it will physically verify every write

    the same BS youve been repeating for years even after you were proven wrong. troll

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1205311]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2022-01-18 20:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:












    Results (54 votes). Check out past polls.

    Notices?