Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 24 Sep 2015 11:26:11 +0200] rev 10921
[migration] don't handle data deletion anymore on schema changes
In most cases when we want to drop some entity/relation type, we don't care
whether hooks are called on their deletion. There is even low chances that some
hooks still exists, based on an old version of the schema. Last but not least,
this is horribly inefficient.
So this should be clearly documented and handled by application's programmer if
desired.
This patch removes unnecessary deletion (because table or column will be later
dropped) and reimplements the case of partial deletion (only one relation
definition among several, hence the database structure isn't modified) using
sql.
Only one test regarding deletion of inlined relation def is added as other cases
seem to be covered by existing tests.
Closes #7023315
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 16:01:43 +0100] rev 10920
[hooks/syncschema] drop unused import
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 16:01:26 +0100] rev 10919
[hooks/syncschema] indentation fix
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 16:00:57 +0100] rev 10918
[server/test] cosmetic whitespace fix
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 16:00:06 +0100] rev 10917
[hooks/syncschema] don't set NOT NULL on inlined relation columns
The NOT NULL constraint was being added on inlined relation cardinality
change while it shouldn't. We don't want this, because this forbids to
add an entity without the relation set at once (it may be added later in
the transaction). This patch fix synchronization hook to stop doing
this.
Closes #6211101
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 24 Sep 2015 12:18:00 +0200] rev 10916
[hooks/syncschema] Turn DropColumnOp into a data operation
While writing a test for a migration issue where "NOT NULL" was added to
an inlined relation column, I ran into a case where the same column was
deleted twice, which of course results in an error. This is because the
"ecrit_par" relation used by the test is ambiguous. I've hence turned
the DropColumnOp into a data operation to ensure we'll delete the column
only once in such case.
Related to #6211101
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 10:16:55 +0100] rev 10915
[server/sources] fix name error in eid_type_source_pre_131
i.e. the eid_type_source implementation used when some pre 3.13.1
database is detected. Regression from 5fbdbbe51867.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 30 Jun 2015 10:06:00 +0200] rev 10914
[repository] deprecate the extid2eid based multi-sources API
This API is cumbersome and lead to obfuscated code because of the callback
mecanism implied when some entity has to be created.
Since we dropped the "true" multi-source, this mecanism is not needed anymore
and one should prefer to use the dataimport API inside its parser instead.
Notice the cwxml parser will trigger the deprecation warning, it should not be
used anymore in favor of ad-hoc parsers.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Mon, 23 Nov 2015 14:37:37 +0100] rev 10913
[ldapfeed] use source's extid2eid, the repo's one will be deprecated in a near future.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 24 Nov 2015 14:36:41 +0100] rev 10912
[ldapfeed / dataimport] port ldapfeed parser to dataimport API
This makes the code easier to understand and will allow to deprecate the old
multi-sources api, based on creation callback through repo.extid2eid.
Currently with this patch, modification dates are not checked, hence
entities will be systematically updated.
We run the import with no hooks, because RQLObjectStore can only add
entities to the system source.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Mon, 23 Nov 2015 14:34:13 +0100] rev 10911
[server/test] document expected packages to run ldap tests
Sylvain Thénault <sylvain.thenault@logilab.fr> [Mon, 23 Nov 2015 14:28:19 +0100] rev 10910
[ldapfeed] simplify ldap2attrs
* tdict argument is never given
* separate value retrieval from setting output (will ease a latter cset)