DB query swapping to file system gitlab #572 Change-Id: I3609ab9207fd01710aeb7c00debae259d1dc08c3 (cherry picked from commit 51cf547b475df8309ca0207c35f97fda0d26abd0)
Direct and synchronization-free access to Layer0 resource class for DB Also converts plenty of legacy Logger use to slf4j Logger. gitlab #493 Change-Id: I0009ed3fd0c039312b1b9f74804cc2de2c39ec9a
Variable optimizations for documents (Simupedia) * More control over computational values served by ReadGraph. * More cacheable Connections (Connection2) gitlab #169 Change-Id: I304de13f97c25661fed2905e33887e315144591e
Replace instantiations of DatabaseException with more specific gitlab #92 Change-Id: I3030bdb2d02492783bda2ca8118c96b48b734c13
Multiple reader thread support for db client gitlab #5 Change-Id: Ia5c189525f2f8277bfc10234c41a1ae47082bb15
Ignore NoSingleResultException in DependenciesRelation Some fixes for NoSingleResultException usage and introducing resultCount field for more detailed exception messages refs #7803 Change-Id: Id633dcfee66c44556de3943c5ec4454e9473f6f3
Dispose ClientChangesImpl ChangeSets to minimize memory footprint This change stems from the fact that org.simantics.db.common.changeset.GenericChangeListener gives ChangeSets as an argument to DB requests which can leave strong references to the ChangeSet instances in the DB QueryProcessor until the DB client garbage collects these requests. Usually DB client request parameters should be immutable, but in this case the request is never listened to for changes so it is OK dispose of the ChangeSet parameter after all DB ChangeListeners are notified. This change adds a Disposable implementation to ClientChangesImpl which minimizes the memory footprint of the class down to 192 bytes compared to ~2^17 bytes. The instances can take up a very considerable amount of memory if not disposed. It has not been uncommon to see multiple gigabytes of memory being spent by these byte[] buffers that are not really used anymore but still referenced. Once more note that this is not a case of memory leakage but simply bad use of memory through over-sized buffers that were GC'ed eventually. refs #6233 Change-Id: I2e96754f106602a4986c37187a9af3bbd64356dc
Fixed CollectionSupportImpl.ResourceList iteration order Implemented CollectionSupportImpl.ResourceList#listIterator methods. Removed use of the deprecated Callback interface in org.simantics.db.ResourceMap. refs #7654 Change-Id: I22ee6da55326bf884b24e63eb2d9ed30fc242771
Optimized EntityInstances and ModelingUtils.search*Shallow queries Shallow queries were previously doing tons of useless queries into dependent ontologies which would have been filtered out anyway. Also EntityInstances.QueryIndex.perform now optimizes two corner cases: * only one search result which is usual for GUID searches * removal of Types:*Entity filter term which is useless because all instances are entities. refs #7415 Change-Id: I89b9495ea51ca8fba4bd40db113c91f4a12932d0
Merge branch 'feature/funcwrite'
Import/export changes. A load. May cause some problems. Exports create Internals instead of blanks if possible. FixExportedOntology treatment now produces tgs that are compatible with Graph Compiler. Import creates L0.ExternalEntity instances for unresolved external references (thus making it fail safe). Note that addBuiltin("http://Projects") was removed from class CoreInitialization because its existence resulted in a non-functioning URI space because: * http://Projects was added as a "built-in resource" when the database is first initialized which means that ReadGraph.getResource("http://Projects") would succeed even when the resource was not yet properly imported from the project ontology * When the project ontology is imported, a new resource is created to represent http://Projects instead of using the existing uninitialized "built-in resource". The L0.ExternalEntity changes made to the standard transferable graph import in this patch caused the code to find the built-in resource for "http://Projects" and think that it has to be a resource that's already properly initialized. This led to the TG import not initializing the resource at all. Previously there was a bug here as well but it was hidden by the fact that the system would import the actual/new "http://Projects" resource from the ontology anyway. This effectively left the uninitialized built-in resource just hanging in the database as trash. refs #7016 Change-Id: I5d9dd8dea4df58cc54d4a6664c112a770ae7f7b3
Make Write-interfaces as @FunctionalInterface for lambdas refs #6998 Change-Id: I7552f2f13c6a034296249b4ebe8909269419ecac