Skip to content
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

Rewrite ckan.logic.converters.convert_to_extras #2151

Closed
wants to merge 2 commits into from

Conversation

ntoll
Copy link

@ntoll ntoll commented Dec 17, 2014

This branch introduces a single change:

  • Rewrite the convert_to_extras function so it behaves in a way that doesn't interfere with other extras and complements the related convert_from_extras function.

I notice there is no test coverage for these.

Fixes #2150.

…oesn't interfere with other extras and complements the related convert_from_extras function. I notice there is no test coverage for these.
@amercader amercader self-assigned this Dec 18, 2014
@amercader
Copy link
Member

@ntoll thanks for this. Can you provide a small test similar to these ones that gets fixed by this patch as part of the PR?

https://github.com/ckan/ckan/blob/master/ckan/new_tests/logic/test_conversion.py#L17

@ntoll
Copy link
Author

ntoll commented Dec 19, 2014

Ahh... I see where the tests are now. Why on earth don't they just go in the tests directory..? You're at risk of having "new_tests", "new_tests2", "more_new_tests" and/or "newer_tests" directories... ;-)

@wardi
Copy link
Contributor

wardi commented Dec 19, 2014

@ntoll I agree completely #1753

@ntoll
Copy link
Author

ntoll commented Dec 22, 2014

OK... not sure how suitable the test I added is. Definitely needs checking given that I've been trying to avoid the internals of CKAN (and I'm therefore not familiar with what's going on or context).

Hope this helps.

+1 on #1753 ;-)

new_pos = 0
if extras:
extras.sort()
new_pos = extras[-1][-2] + 1 # e.g. ('extras', 5, 'value')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You refactored line 16 into new lines 15-18 and TBH I find the original easier to understand.

@amercader
Copy link
Member

OK, several things going on here :)

I've been having a look at this and could reproduce the issue using your extension (you get the exception when you provide more free extras than custom fields, otherwise free extras will make custom fields disappear (as described in #1894)).

One thing to note is that on 2.2.1 (the one that your instance targets) you can not mix custom fields that get internally transformed into extras with free form extras when using the core converter. As @davidread mentioned in the previous comment the docs said otherwise but unfortunately this was a a mistake left from bad merging (this is now fixed #2259).

AFAICT the issue is fixed when using master or the release-v2.3 branch. The test you provided passes for me in current master if I comment out the assert not ('extras',) in data bit.

Looking at patching this in previous versions, I think we agreed that it was too big a change and broke the API, as it required a change in logic to check that the free extras don't clash with the custom ones (for full context see [1]). I'd suggest that you keep using your custom convert_to_extras converter on your extension until you can upgrade to 2.3.

Finally, I'm not saying that this patch is no longer relevant, as you mention it may do things in a safer way ( I need to have another look with more time), but is not directly relevant to fix the original exception you reported.

Hope all of this makes sense.

[1] https://lists.okfn.org/pipermail/ckan-dev/2014-October/008170.html

@ntoll
Copy link
Author

ntoll commented Feb 12, 2015

Hey hey... great stuff and glad to hear the problem will be fixed in the next release. When is that scheduled to be?

@wardi
Copy link
Contributor

wardi commented Jun 21, 2016

The free-form vs. converted extras problem will be solvable after #3072 is adapted for dataset extras. We'll have a separate namespace available for each plugin so we could easily have these values live side-by-side (and remove the extras table while we're at it)

@rossjones
Copy link
Contributor

Looks like this PR is now unnecessary? Suggest we close it.

@davidread davidread closed this Jun 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom dataset fields causes IndexError when arbitrary other "extra" fields are used.
5 participants