issue regarding deletion of moved columns

[esc]

As reported in #137 there is an issue with removing on-disk columns that had been created previously elsewhere:

http://nbviewer.ipython.org/gist/alimanfoo/6cc03872fe8054e63860/bcolz_ctable_delcol.ipynb

Basically, the problem is that when moving a column into the ctable, the rootdir of that carray isn't being updated.

[FrancescAlted]

I think a fix for this should be in 0.9 yes.

[esc]

I attached a pull-request to this issue which should fix the erroneous behavior in question. @alimanfoo maybe you could confirm it solves the issue.

[alimanfoo]

Thanks @esc, this works for me, i.e., the rootdir for the originally-on-disk column is removed after calling delcol, notebook rerun with this PR.

FWIW I think it would be better to make a shallow copy (view?) of the originally-on-disk carray object passed in to addcol before modifying the rootdir attribute. As it currently stands, passing an on-disk carray into addcol has the side-effect of modifying the original carray object's rootdir, which is potentially confusing if the user still wants to use the original carray object in any way, because they would (like me) probably expect it to still have the original rootdir it was created with. Make sense?

[esc]

Yes, I fear that this feature and how it should work exactly will warrant some more in-depth discussions.

[esc]

I've taken it to the mailinglist.

[esc]

The mailinglist was fairly quiet so I have implemented a full copy of the column. I think this is a) what users would expect and b) delegates the internals to the carray itself. Note however, that when adding an in-memory column the python object is not copied, which may cause confusion yet again.

In addition, this feature isn't fully cooked yet so this is to be considered as more of an interim bug-fix and the API will likely undergo some more refactoring.

[alimanfoo]

FWIW as a user I'm comfortable with this solution.

On Saturday, 11 April 2015, Valentin Haenel notifications@github.com
wrote:

The mailinglist was fairly quiet so I have implemented a full copy of the
column. I think this is a) what users would expect and b) delegates the
internals to the carray itself. Note however, that when adding an in-memory
column the python object is not copied, which may cause confusion yet again.

In addition, this feature isn't fully cooked yet so this is to be
considered as more of an interim bug-fix and the API will likely undergo
some more refactoring.

Reply to this email directly or view it on GitHub
#170 (comment).

Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health http://cggh.org
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287721

[esc]

Ok, it's decided, we are taking it.

[esc]

Aight, here goes.