>> I haven't been tracking the pysqlite discussion either, but one con
>> you missed is that regardless of pro #1 people will almost certainly
>> apply it to problems for which it is ill-suited, reflectly poorly on
>> both Python and SQLite.
Fredrik> the arguments keep getting more and more weird.
Fredrik> is there *any* part of the standard Python distribution that
Fredrik> cannot be applied to problems for which it is ill-suited?
To many people "SQL" in the name implies "big databases". I know from
personal experience at work. The powers-that-be didn't want to support
another database server (we already have Sybase) and didn't want our group's
experimental data "polluting" the production database, so the folks who
wanted it went the SQLite/pysqlite route. They were immediately bitten by
the multiple reader/single writer limitation and they tried to cram too much
data into it, so performance further sucked.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4