Related to #141 #166 #191, this PR switches the default SQL-backend to in-memory & add general catch of sqlite3.Error from owlready2 accessing to SQL backend as a disk-file, to avoid disrupting Designator functionality.
Specifically,
OntologyManager.create_ontology_world() -> owlready2.World.set_backend(), where sqlite3 DB access commands are invoked. Errors may happen upon a corrupt db or concurrent accesses, or a typical OperationalError would be raised amid debug process, which if sometimes prematurely ended (eg by pause/stop-debug in IDE), could result in a locked-db file on disk.
Such errors would be treated in another PR, or even better by owlready2 itself.
https://stackoverflow.com/a/2741015/4767815
Also, A quick resolution is deleting the SQL file on disk.
SQL backend essentially acts like a cache that is only required during program run, one if not-existing is automatically re-generated afresh from contents from the .owl, which together with all ontology data (including dynamically created concepts) can be saved anyway at program exit.
OntologyManager: add main_ontology_sql_backend attr, allowing users to specifically set path to an SQL backend file (no need to already exist), otherwise it will be in-memory.
OntologyManager.load_ontology(): in case ontology_iri is a local relative path & non-existing, make sure the file creating location is under ontology_search_path, which is settable by users
test_ontology: only test sql_backend being saved to file in case of non-in-memory backend.
Related to #141 #166 #191, this PR switches the default SQL-backend to
in-memory
& add general catch ofsqlite3.Error
from owlready2 accessing to SQL backend as a disk-file, to avoid disrupting Designator functionality.Specifically,
OntologyManager.create_ontology_world()
->owlready2.World.set_backend()
, where sqlite3 DB access commands are invoked. Errors may happen upon a corrupt db or concurrent accesses, or a typicalOperationalError
would be raised amid debug process, which if sometimes prematurely ended (eg by pause/stop-debug in IDE), could result in a locked-db file on disk. Such errors would be treated in another PR, or even better byowlready2
itself. https://stackoverflow.com/a/2741015/4767815Also, A quick resolution is deleting the SQL file on disk. SQL backend essentially acts like a cache that is only required during program run, one if not-existing is automatically re-generated afresh from contents from the
.owl
, which together with all ontology data (including dynamically created concepts) can be saved anyway at program exit.OntologyManager
: addmain_ontology_sql_backend
attr, allowing users to specifically set path to an SQL backend file (no need to already exist), otherwise it will bein-memory
.OntologyManager.create_main_ontology_world()
: catchsqlite3.Error
OntologyManager.load_ontology()
: in caseontology_iri
is a local relative path & non-existing, make sure the file creating location is underontology_search_path
, which is settable by userstest_ontology
: only test sql_backend being saved to file in case of non-in-memory backend.