| commit | 258a07028a264304eb2423581fbc872b570b448f | |
| author | Jeff Hemphill <jhemphill@fb.com> | |
| Fri, 30 Apr 2021 21:45:23 +0000 (30 14:45 -0700) | ||
| committer | Facebook GitHub Bot <facebook-github-bot@users.noreply.github.com> | |
| Fri, 30 Apr 2021 21:46:40 +0000 (30 14:46 -0700) | ||
| tree | d132a0513cb8caabbd8c91c76310b0511b172b32 | treesnapshot (tar.gz zip) |
| parent | 3349c70bccf8dccbf640654366b8452ab224de36 | commitdiff |
Add group and permissions settings to the Facts DB
Summary:
This is part of a larger effort to improve the performance of native Facts in CLI mode.
Today, we insert the unix user's uid into the Facts DB's path, so different unix users will always build and connect to different DBs.
This is sound from a permissions standpoint, but it does mean most people have two DBs on their disk. One belongs to `apache` and gets updated by your HHVM webserver. The other is owned by your unix user (like `jhemphill`) and only gets updated when you run a script in CLI mode as yourself.
When you build or update the DB that belongs to your unix user, you get a terrible experience. We build the DB "in a background thread". But your CLI-mode script is probably fairly short-lived. After your script is done, we'll probably still be writing to the DB, and we'll probably need to hold your process open while we finish updating the DB.
People are wondering why their "hello world" scripts need to stay open for twenty minutes after they've printed "hello world". People ctrl+c these scripts out of impatience. It's not great.
This diff allows you to specify a group and permissions bitmask for the DB. SQLite won't let you read a wal-mode DB without rw permissions, so if you want to take advantage of `Autoload.DB.Group` you'll probably want to set your permissions to 0664.
After this diff, we can change the configuration so different users will be able to connect to the same DB. Then each devserver can have just one DB, usable in both CLI-standalone and CLI-server mode.
Reviewed By: fredemmott
Differential Revision: D28016712
fbshipit-source-id: 5a64d250802c9d1100abfe32c9eca7e2250fad2f
Summary:
This is part of a larger effort to improve the performance of native Facts in CLI mode.
Today, we insert the unix user's uid into the Facts DB's path, so different unix users will always build and connect to different DBs.
This is sound from a permissions standpoint, but it does mean most people have two DBs on their disk. One belongs to `apache` and gets updated by your HHVM webserver. The other is owned by your unix user (like `jhemphill`) and only gets updated when you run a script in CLI mode as yourself.
When you build or update the DB that belongs to your unix user, you get a terrible experience. We build the DB "in a background thread". But your CLI-mode script is probably fairly short-lived. After your script is done, we'll probably still be writing to the DB, and we'll probably need to hold your process open while we finish updating the DB.
People are wondering why their "hello world" scripts need to stay open for twenty minutes after they've printed "hello world". People ctrl+c these scripts out of impatience. It's not great.
This diff allows you to specify a group and permissions bitmask for the DB. SQLite won't let you read a wal-mode DB without rw permissions, so if you want to take advantage of `Autoload.DB.Group` you'll probably want to set your permissions to 0664.
After this diff, we can change the configuration so different users will be able to connect to the same DB. Then each devserver can have just one DB, usable in both CLI-standalone and CLI-server mode.
Reviewed By: fredemmott
Differential Revision: D28016712
fbshipit-source-id: 5a64d250802c9d1100abfe32c9eca7e2250fad2f