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
Resource extras can not be updated #2158
Comments
@rossjones git bisect fingers f79a20a, but 699d226 (its parent) seems to be broken too in a slightly different way: I need to update a non-extra field along with the extra for the resource extras to be updated |
Our tests suck. We need to fix this. I'll take a look when I am back off holiday if you want to assign to me. I sort of hoped @davidread's recent fix for resource updates might be responsible, but if bisect is suggesting this commit .... |
I've started this ^^ PR with some tests. The extra is written to the session, but it is prevented from being flushed due to the CkanSessionExtension thinking there is nothing changed, as session.is_modified is coming back as False for some reason. |
I've been looking at the second problem - "I need to update a non-extra field along with the extra for the resource extras to be updated" - and it seems to be a problem that we've perhaps always had. The model test fails on CKAN 2.1 (August 2013). |
I've added a test for the first issue - changing url and the extra only saves the new url. Here's the tests, hacked to work on old versions of ckan too: |
Hi @wardi ! |
Hi @wardi, @rossjones & and @davidread could you give us a lead to this fix? |
Sorry to chase you again on that @wardi, I could spend some time trying to fix this but so far I've not even been able to put my finger on the actual cause of the problem! Could you give us a lead? |
@clementmouchet sorry, I don't understand. It looks like this problem or one like it has existed for a very long time so bisecting isn't helping. @davidread has created a test that reproduces the problem so the next thing I would do is step in to the failing test with a debugger. |
Trying to wrap my head around this, one thing that seems suspicious is that we are using the JsonDictType for the
|
@amercader ok, try |
@wardi you mean here? diff --git a/ckan/lib/dictization/model_save.py b/ckan/lib/dictization/model_save.py
index 4ba4788..878389e 100644
--- a/ckan/lib/dictization/model_save.py
+++ b/ckan/lib/dictization/model_save.py
@@ -50,7 +50,7 @@ def resource_dict_save(res_dict, context):
del obj.extras[delete_me]
obj.state = u'active'
-
+ obj.extras = obj.extras
session.add(obj)
return obj I doesn't seem to make much difference but I see where you are coming from |
Yeah, that what I was thinking -- maybe there's some sneaky code that checking if the thing you're assigning has changed. Could always go deeper: Assign some other object first, and/or pass to dict() before assigning. Or better yet let's just not treat .extras as mutable in the code that uses it, because that doesn't work. |
Resource `extras` were being ignored on `resource_udpate`. The rest of the resource field got updated but no the extras. The resource `extras` field is using a custom `JsonDictType`, and according to SQLAlchemy documentation: > Note that the ORM by default will not detect “mutability” on such a > type - meaning, in-place changes to values will not be detected and > will not be flushed. Without further steps, you instead would need to > replace the existing value with a new one on each parent object to > detect changes. Replacing `obj.extras` with a new dict solves the issue http://docs.sqlalchemy.org/en/rel_0_9/core/custom_types.html#marshal-json-strings
Replacing the extras with a brand new dict did the trick and solved the two issues. Fix is on @davidread's branch: #2159 |
We need to assign a new extras dict so the change is detected
Nice job !! |
fixed in #2159 |
Resource `extras` were being ignored on `resource_udpate`. The rest of the resource field got updated but no the extras. The resource `extras` field is using a custom `JsonDictType`, and according to SQLAlchemy documentation: > Note that the ORM by default will not detect “mutability” on such a > type - meaning, in-place changes to values will not be detected and > will not be flushed. Without further steps, you instead would need to > replace the existing value with a new one on each parent object to > detect changes. Replacing `obj.extras` with a new dict solves the issue http://docs.sqlalchemy.org/en/rel_0_9/core/custom_types.html#marshal-json-strings Conflicts: ckan/lib/dictization/model_save.py
Resource `extras` were being ignored on `resource_udpate`. The rest of the resource field got updated but no the extras. The resource `extras` field is using a custom `JsonDictType`, and according to SQLAlchemy documentation: > Note that the ORM by default will not detect “mutability” on such a > type - meaning, in-place changes to values will not be detected and > will not be flushed. Without further steps, you instead would need to > replace the existing value with a new one on each parent object to > detect changes. Replacing `obj.extras` with a new dict solves the issue http://docs.sqlalchemy.org/en/rel_0_9/core/custom_types.html#marshal-json-strings Conflicts: ckan/lib/dictization/model_save.py
Resource `extras` were being ignored on `resource_udpate`. The rest of the resource field got updated but no the extras. The resource `extras` field is using a custom `JsonDictType`, and according to SQLAlchemy documentation: > Note that the ORM by default will not detect “mutability” on such a > type - meaning, in-place changes to values will not be detected and > will not be flushed. Without further steps, you instead would need to > replace the existing value with a new one on each parent object to > detect changes. Replacing `obj.extras` with a new dict solves the issue http://docs.sqlalchemy.org/en/rel_0_9/core/custom_types.html#marshal-json-strings Conflicts: ckan/lib/dictization/model_save.py
Resource `extras` were being ignored on `resource_udpate`. The rest of the resource field got updated but no the extras. The resource `extras` field is using a custom `JsonDictType`, and according to SQLAlchemy documentation: > Note that the ORM by default will not detect “mutability” on such a > type - meaning, in-place changes to values will not be detected and > will not be flushed. Without further steps, you instead would need to > replace the existing value with a new one on each parent object to > detect changes. Replacing `obj.extras` with a new dict solves the issue http://docs.sqlalchemy.org/en/rel_0_9/core/custom_types.html#marshal-json-strings
We need to assign a new extras dict so the change is detected
* release-v2.2.2: (37 commits) Update version number for release 2.2.2 Rebuild frontend [ckan#2107] Don't create a source link if not a valid url [ckan#2037] PEP8 [ckan#2037] Cherry-pick functional test for dataset creation [ckan#2037] Fix exception on resource creation [ckan#1909] phix phantomjs peerinvalid phailure Update changelog ahead of 2.2.2 release [ckan#2320] Don't assume resource format is there [ckan#2324] Don't "normalize" resource URL in recline view [ckan#2319] Clean up field names before rendering the table Compile updated translation files Update translations from Transifex [ckan#2283] Pack template_legacy resources on python setup.py install [ckan#2158] Replace all resource extras on update so they don't get lost [ckan#2044] Fix datastore docs link [ckan#2272] Fix docs that say Celery will be be installed [ckan#1647] Stats extension. 'Largest Groups' links lead either to organizations or to groups page [ckan#1649] Stats extension. Changed tests [ckan#1649] Stats extension. Tag counter works properly ...
Fixes ckanext-dgu#275 using fix from ckan master ckan#2158
^ this creates a new package with one resource including one extra "newfield"
In the database tables resource and resource_revision both contain:
^ this successfully updates the url, but the newfield extra remains unchanged.
In the database we see in resource (newfield was not updated):
But in resource_revision the correct data is stored (new revision on top is correct):
Maybe vdm-related? There is also a code in package_update that avoids creating revisions that could be the cause.
The text was updated successfully, but these errors were encountered: