Closed funderburkjim closed 4 years ago
For now, just add sqlite/input.txt to inventory.txt with the D (delete) action.
Then generate all the web directories according to sh redo_cologne_all.sh
in v00.
This is scans/MWScan/2014/web/sqlite/old Also mentioned in #1 above. Do this manually.
Do this manually.
Once?
Once?
Yes. I made the (temporary) old directory for some experiment with MW, but forgot to delete it at that time, as I should have done after the experiment was over.
This is done in the v00/check_inventory directory, via
python delete_empty_sqlite.py > delete_empty_sqlite.txt
This can be rerun, but needs to be done only once.
delete_empty_sqlite.txt shows the deleted files.
It also shows (the top 9 lines) the non-empty sqlite files in all the dictionaries (but does not show mw.sqlite, etc. (that is, it doesn't show sqlite versions of the dictionary digitizations)).
There is a programmatic reason that all those empty xxxab.sqlite files show up: At a certain point in the display (of any dictionary), non-existing sqlite files are created ! This is confusing, so the following adjustment is made.
webtc/basicadjust.php asks webtc/dal.php for a handle ($dal_ab) to the xxxab.sqlite database of
abbreviation tooltips.
When basicadjust makes this request, it doesn't know if xxxab.sqlite exists for dictionary xxx.
Later, if basicadjust finds an <ab>
tag when examining the xml data for the given citation, it uses the getgeneral method of the handle.
The constructor of the Dal class provides the handle mentioned above as attribute file_db of the constructed Dal object. It uses the path to the xxxab.sqlite file, using the PHP PDO (PHP Data Object) class to get file_db. When the path to xxxab.sqlite exists, PDO sets things up so subsequent SQL requests will work. But when the path to xxxab.sqlite does not exist, PDO constructs xxxab.sqlite as an empty file. [NOTE: PHP probably does this because the sqlite3.exe program works just like this.]
To avoid this automatic file creation, we can do our own checking if xxxab.sqlite file exists. If it exists, then we make the calls to PDO as above. But if xxxab.sqlite file does NOT exist, then we do not call PDO, but just set file_db attribute of the constructed Dal class to be null. This 'trick' works since the getgeneral method of the Dal object checks if file_db is null.
We can apply the change to one of the dictionaries (say KRM) that we know has no krmab.sqlite file.
python generate.py krm inventory.txt makotemplates ../../KRMScan/2014/web
Now, use one of the displays (say Basic display) to look up something in krm (say DAtu 'gamx' (slp1)). The display looks normal (👍 )
Then look in KRMScan/2014/web/sqlite directory -- we expect not to find krmab.sqlite (👍 ).
So, things look as expected.
sh redo_cologne_all.sh
All the currently unneeded files (as mentioned in #1) in dictionary web/sqlite directories have now been taken care of.
All I can do is adore what you do so systematically. It seems as health has issues, not that Jim had health issues.
As mentioned in this comment of #1, web/sqlite/input.txt is an intermediate file which can be deleted. The reason for deleting it is to save space and remove clutter. It is recreated each time the web/sqlite/redo.sh script is run.