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
Using homogenize() after denormalize() results in some rows without row_names #756
Comments
The kludge I'm using to get around this is to add the following immediately after invoking
This basically re-creates the table and forces the addition of row_names to all rows. |
I think this can be partially solved in the case where the |
Could I have never used row names for anything explicitly in my code. So I don't understand why it's necessary for To me, it feels wrong that the sequence of commands I outlined above ( |
Hmm, that's an idea. I'll reopen the issue. agate lacks a maintainer, so I'm just stepping in to fix some easy issues and close feature requests that will never be resolved. |
I found a simple solution similar to #691. |
I noticed recently that if you use
table.homogenize()
to fill in missing rows after earlier runningtable.denormalize()
, the new filler rows will not have row_names, while the original rows will have row_names.The problem is that this will lead to later errors when you try to invoke methods like
.order_by()
on the resulting table.Because some rows have row_names and others don't, you'll get this error message:
This error can be reproduced with the following test code:
I don't use row_names myself, so I don't know why it's necessary to have
.denormalize()
automatically generate them. But I assume preserving that is important, so I guess the fix would be to make.homogenize()
also generate row_names?The text was updated successfully, but these errors were encountered: