Wed, 05 Oct 2016 09:38:05 +0200 [massive store] Use a slave specific table for relation insertion in the massive store
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 05 Oct 2016 09:38:05 +0200] rev 11784
[massive store] Use a slave specific table for relation insertion in the massive store * attribute a random id to the store * add a column containing this id in the cwmassive_initialized table * separate generic `master_init` which create the cwmassive_initialized table from rtype specific initialization which must be done in each slave now * delay removal of table indexes to `finish` * get back relations from each table on `finish` Similar work still has to be done for entities insertion - which will allow more cleanup to the constraints handling which is still rough for now. Related to #15538303
Tue, 04 Oct 2016 13:14:35 +0200 [massive store] docstring and __init__ cleanup
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 04 Oct 2016 13:14:35 +0200] rev 11783
[massive store] docstring and __init__ cleanup
Tue, 04 Oct 2016 13:14:18 +0200 [massive store] Drop dead code
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 04 Oct 2016 13:14:18 +0200] rev 11782
[massive store] Drop dead code This function is never used
Fri, 30 Sep 2016 17:34:59 +0200 [massive store] Reintroduce methods that are necessary to properly handle master/slave configuration
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 30 Sep 2016 17:34:59 +0200] rev 11781
[massive store] Reintroduce methods that are necessary to properly handle master/slave configuration Related to #15538303
Wed, 28 Sep 2016 09:02:14 +0200 [massive store] Follow configuration of the metadata generator
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 28 Sep 2016 09:02:14 +0200] rev 11780
[massive store] Follow configuration of the metadata generator Don't drop constraints and indexes for tables that are ignored by the metadata generator given to the store. One may now easily disable insertion of e.g. created_by / owned_by by removing them from the MetadataGenerator.META_RELATIONS set, in which case indexes for associated table won't be removed by the massive store.
Mon, 17 Oct 2016 16:53:28 +0200 [dataimport] make MetadataGenerator.META_RELATIONS customizable
Adrien Di Mascio <Adrien.DiMascio@logilab.fr> [Mon, 17 Oct 2016 16:53:28 +0200] rev 11779
[dataimport] make MetadataGenerator.META_RELATIONS customizable This should be done on the instance rather than on the class
Wed, 28 Sep 2016 08:57:48 +0200 [massive store] Rework constraint/index handling
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 28 Sep 2016 08:57:48 +0200] rev 11778
[massive store] Rework constraint/index handling The basic idea is to keep the primary constraint on entities.eid since it's heavily used in metadata insertions. Other option would have been to drop / recreate but its very costly on big database, and the index is used for insertion into the entities table itself, so it's not worth droping it at a first glance. Also, keeping it avoids to systematically drop all constraints which depends on it. We may thus now lazily drop constraints, only on insertion of some etype/rtype for the related table. Related to #15538359
Tue, 27 Sep 2016 12:02:07 +0200 [massive store] Lazy removal of constraints and metadata indexes
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 27 Sep 2016 12:02:07 +0200] rev 11777
[massive store] Lazy removal of constraints and metadata indexes They should not be removed during store's init, because we may want to query the database with its index between store creation and call to prepare_insert* (e.g. to build the extid2eid map). Along the way: * rename drop_metadata_constraints into drop_metadata_indexes, because that's what it does * rework a bit impacted tests Closes #15538359
Mon, 17 Oct 2016 14:50:47 +0200 [repository] Drop the index on entities.type
Sylvain Thénault <sylvain.thenault@logilab.fr> [Mon, 17 Oct 2016 14:50:47 +0200] rev 11776
[repository] Drop the index on entities.type It should be now only used in maintenance queries in checkintegrity. Those are not worth maintaining it. Closes #15538317
Thu, 06 Oct 2016 12:11:23 +0200 [source] Drop source mapping handling
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 06 Oct 2016 12:11:23 +0200] rev 11775
[source] Drop source mapping handling It was only used by the cwxmlparser which has been deleted. This is too complex for litle benefit, we don't want to maintain that in cubicweb.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip