Skip to content
Snippets Groups Projects
Select Git revision
  • restricted-sqlite-strategies
  • compare-structured-sql-dumps
  • main default protected
  • 235.backup-and-recovery.recovery
  • mypy
  • real-spender
  • github/fork/tp-la/real-spender
  • 260.metric-rejected-zkaps
  • implicit-lease-renewal-problems
  • mach-nix
  • github/fork/tp-la/deep-traverse
  • v0.0
12 results

model.py

  • Jean-Paul Calderone's avatar
    05b4220e
    some database interaction improvements · 05b4220e
    Jean-Paul Calderone authored
    removing the operation-id may not actually be an improvement ... it is a
    simplification, though.  However it requires us to load all the rows into
    python and then send them back to the database instead of only loading them.
    I thought removing the operation-id from the in-use table would be a win and
    maybe it is but not for the reason I thought - sqlite3 emits the same code
    whether you do `in [foo]` or `in (select x from [foo])` as far as I can tell.
    
    Still, I like the simplification so we'll go with it for now.
    05b4220e
    History
    some database interaction improvements
    Jean-Paul Calderone authored
    removing the operation-id may not actually be an improvement ... it is a
    simplification, though.  However it requires us to load all the rows into
    python and then send them back to the database instead of only loading them.
    I thought removing the operation-id from the in-use table would be a win and
    maybe it is but not for the reason I thought - sqlite3 emits the same code
    whether you do `in [foo]` or `in (select x from [foo])` as far as I can tell.
    
    Still, I like the simplification so we'll go with it for now.