-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Importing existing entities re-adds statements #22
Importing existing entities re-adds statements #22
Comments
Wait, I forgot that this is a MediaWiki extension, so it has access to the same config that Wikibase uses, and can look up the entity namespaces :) fix incoming. |
Instead of assuming that all entities are in namespace 0 (which is only true in a Wikidata-like installation, but not in a default Wikibase installation, and even then only for items, not properties), use all entity namespaces from the local configuration. (Use array_values to make the keys numeric to make sure the database wrapper doesn’t try to interpret the string keys ('item', 'property').) Also, if we can’t find the entity, throw an exception instead of returning count 0: it’s better to fail the import than to duplicate statements. Fixes filbertkm#22.
Instead of assuming that all entities are in namespace 0 (which is only true in a Wikidata-like installation, but not in a default Wikibase installation, and even then only for items, not properties), use all entity namespaces from the local configuration. (Use array_values to make the keys numeric to make sure the database wrapper doesn’t try to interpret the string keys ('item', 'property').) Also, if we can’t find the entity, throw an exception instead of returning count 0: it’s better to fail the import than to duplicate statements. Fixes filbertkm#22.
Instead of assuming that all entities are in namespace 0 (which is only true in a Wikidata-like installation, but not in a default Wikibase installation, and even then only for items, not properties), use all entity namespaces from the local configuration. (Use array_values to make the keys numeric to make sure the database wrapper doesn’t try to interpret the string keys ('item', 'property').) Also, if we can’t find the entity, throw an exception instead of returning count 0: it’s better to fail the import than to duplicate statements. Fixes filbertkm#22.
Instead of assuming that all entities are in namespace 0 (which is only true in a Wikidata-like installation, but not in a default Wikibase installation, and even then only for items, not properties), take the actual namespace of the requested entity from an injected EntityNamespaceLookup. Also, if we can’t find the entity, throw an exception instead of returning count 0: it’s better to fail the import than to duplicate statements. Fixes filbertkm#22.
Instead of assuming that all entities are in namespace 0 (which is only true in a Wikidata-like installation, but not in a default Wikibase installation, and even then only for items, not properties), take the actual namespace of the requested entity from an injected EntityNamespaceLookup. Also, if we can’t find the entity, throw an exception instead of returning count 0: it’s better to fail the import than to duplicate statements. Fixes filbertkm#22.
I encountered the same problem, took me a morning to debug. I just dropped this line: |
Any clue when / if this can be fixed? I am running into this sync issue as well...Would love to help but php is not my strongest point. |
Depending on local setup, if you re-import entities that you’ve already imported before, the importer will add all the statements again, leaving you with duplicate statements.
This query in
PagePropsStatementCountLookup::getStatementCount
is the culprit:In a default Wikibase setup, Item is namespace #120, and Property is namespace #122 (see
Wikibase/repo/config/Wikibase.example.php
), so the query returns no result, which is interpreted as a statement count of 0:Even if you configure your Wikibase to put items in the main namespace, as on Wikidata, I think the importer would still duplicate statements on properties.
I’m not sure what the best way to solve this is, but perhaps it would be a good idea to throw an exception instead of returning 0 if the query returns no results: if we can’t find the entity, there must be something wrong, right?
Workaround: change the query to select, e. g.,
'page_namespace' => [ 120, 122 ]
.The text was updated successfully, but these errors were encountered: