response to get-models differs between 4.0 and 3.4.1
Felix Lohmeier
I tested if the openrefine-client might already work with the 4.0 branch and found that the response to the get-models command has changed.
OpenRefine 3.4.1
{
"columnModel": {
"columns": [
{
"cellIndex": 0,
"originalName": "a",
"constraints": "{}",
"type": "",
"format": "default",
"title": "",
"description": "",
"name": "a"
},
{
"cellIndex": 1,
"originalName": "b",
"constraints": "{}",
"type": "",
"format": "default",
"title": "",
"description": "",
"name": "b"
},
{
"cellIndex": 2,
"originalName": "c",
"constraints": "{}",
"type": "",
"format": "default",
"title": "",
"description": "",
"name": "c"
}
],
"columnGroups": [],
"keyColumnName": "a",
"keyCellIndex": 0
},
(...)
OpenRefine 4.0-snapshot
{
"columnModel": {
"columns": [
{
"originalName": "a",
"name": "a"
},
{
"originalName": "b",
"name": "b"
},
{
"originalName": "c",
"name": "c"
}
],
"keyCellIndex": 0,
"keyColumnName": "a"
},
(...)
Paul's Python client expects the "cellIndex" information (see https://github.com/opencultureconsulting/openrefine-client/blob/2735db3f3fb06812010d430611a731217e85e200/google/refine/refine.py#L416). Should I check how the client works without cellIndex or do you intend to change that (e.g. for backward compatibility)?
The video was very impressive! Thanks a lot for it.
Antonin Delpeuch (lists)
Hi Felix,
Yes indeed, that's one of the breaking changes. So far I do not
know if it makes sense to write a "Migration guide" for extensions
like I did for previous breaking changes (JSON handling, CSRF
tokens…), because there are really a lot of them in the Java API.
I could do it for the HTTP API (where there are much less changes)
but we have always stated that this HTTP API was not intended for
public use, so it would probably send out confusing messages.
Anyway, I can still answer your question here.
Yes the `cellIndex` field was dropped, because it is no longer useful in the new architecture (because reordering columns is done lazily, there is no big cost associated to it as it was previously the case in the in-memory set-up). So, the index of a column is simply its index in the list of columns returned by the API (so the first one has cellIndex 0, the second 1, and so on).
I also took this opportunity to remove the unused fields which you spotted below - they had been introduced in the Data Package integration but had never been exposed in the UI.
Happy to answer more questions like this if you have any :)
Antonin
--
You received this message because you are subscribed to the Google Groups "OpenRefine Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrefine-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openrefine-dev/1297a38a-5d26-4d90-9b6e-630411b728afn%40googlegroups.com.
Felix Lohmeier
I could do it for the HTTP API (where there are much less changes) but we have always stated that this HTTP API was not intended for public use, so it would probably send out confusing messages.
Yes the `cellIndex` field was dropped, because it is no longer useful in the new architecture (because reordering columns is done lazily, there is no big cost associated to it as it was previously the case in the in-memory set-up). So, the index of a column is simply its index in the list of columns returned by the API (so the first one has cellIndex 0, the second 1, and so on).
Happy to answer more questions like this if you have any :)
- import option character encoding (seems to have no effect at the moment)
- import line-based text files
- export to xls, xlsx, ods
