importing a bad csv file in module, and subsequent correction causes issues
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
Triaged
|
Undecided
|
OpenERP's Framework R&D |
Bug Description
There are a few strands to this. Some I can't confirm except to say they occur on my machine. I'm not even sure what the bug is I'm reporting.
1. If the relative path of a symlink includes a hyphen then I think the import doesn't work. It chucks a no reference error in the client. On checking, this is because there are no entries in ir.model.data when _get_id is called, the code excepts, silently passes and continues. Often this means the error at the end is in no way related to the actual error, as it excepts all the way through, but doesn't raise immediately so the exception gets overwritten. I think the csv importer deals with it fine, so when debugging you see the right lines in the right place. I think the issue might be where ir.model.data gets populated. I seem to remember that xml has an issue with hyphens from when installing the bzr-xmloutput plugin for bazaar where you need to rename the directory with an underscore.
2. Upon doing a number of things, like renaming the directory, reformatting all csv's so everything was stored as strings in double quotes, it still failed on an existing database (updated) but would work fine on a fresh database. Somehow it exhibits the same behaviour where ir.model.data search returns an empty list. So maybe some entry is left over. Deleting the module entry in GUI, and then restarting the server and updating the modules it worked.
3. This behaviour is not limited to the hyphen problem. I had an entry called Travel, Meals and Entertainment in the chart, it was not enclosed in quotes. This brought about a quite correct error of no reference to parent xxx.Meals and Entertainment. However after correcting the csv's it starts to exhibit the above error.
4. There is additional behaviour that is exhibited sometimes, if the file is corrected without following the above steps. And that is that it will just not import anything at all, and start any configuration actions.
I have experienced on latest 6.0.2 sources (as of yesterday) on Linux, and have user reports confirmed on Windows as well. The best way to see this behaviour is to set a breakpoint at line 733 or 735 (or the exception line) in the ORM within _get_id function and step over, while using a bad csv file or directory.
I'm not concerned that it kicks up a fuss about bad csv files and stupid developer symlinks and chucks an error, but that it is so difficult to recover after correcting - and I think the bug is more related to ir.model.data than csv import. Maybe just throw an exception if a hyphen is in the path.
While I highly do not recommend this, if you want files to test, good files is latest rev of lp:~gdgellatly/openerp-au/l10n-nz-minimal-coa, bad files is rev 3 of the same. Just do it on something you don't mind breaking (a fresh database is fine).
Changed in openobject-server: | |
status: | New → Triaged |
I just went off to work on something else, and I think I may have found the
root cause. Unlike xml, csv is effectively always noupdate=1. So I geuss
what I'm saying is that perhaps, in the case of a module csv import that
this is only set to true if the import completes successfully.
On Tue, May 24, 2011 at 10:54 AM, Graeme Gellatly <<email address hidden>
> wrote:
> Public bug reported:
>
> There are a few strands to this. Some I can't confirm except to say
> they occur on my machine. I'm not even sure what the bug is I'm
> reporting.
>
> 1. If the relative path of a symlink includes a hyphen then I think the
> import doesn't work. It chucks a no reference error in the client. On
> checking, this is because there are no entries in ir.model.data when
> _get_id is called, the code excepts, silently passes and continues.
> Often this means the error at the end is in no way related to the actual
> error, as it excepts all the way through, but doesn't raise immediately
> so the exception gets overwritten. I think the csv importer deals with
> it fine, so when debugging you see the right lines in the right place.
> I think the issue might be where ir.model.data gets populated. I seem
> to remember that xml has an issue with hyphens from when installing the
> bzr-xmloutput plugin for bazaar where you need to rename the directory
> with an underscore.
>
> 2. Upon doing a number of things, like renaming the directory,
> reformatting all csv's so everything was stored as strings in double
> quotes, it still failed on an existing database (updated) but would work
> fine on a fresh database. Somehow it exhibits the same behaviour where
> ir.model.data search returns an empty list. So maybe some entry is left
> over. Deleting the module entry in GUI, and then restarting the server
> and updating the modules it worked.
>
> 3. This behaviour is not limited to the hyphen problem. I had an entry
> called Travel, Meals and Entertainment in the chart, it was not enclosed
> in quotes. This brought about a quite correct error of no reference to
> parent xxx.Meals and Entertainment. However after correcting the csv's
> it starts to exhibit the above error.
>
> 4. There is additional behaviour that is exhibited sometimes, if the
> file is corrected without following the above steps. And that is that
> it will just not import anything at all, and start any configuration
> actions.
>
> I have experienced on latest 6.0.2 sources (as of yesterday) on Linux,
> and have user reports confirmed on Windows as well. The best way to see
> this behaviour is to set a breakpoint at line 733 or 735 (or the
> exception line) in the ORM within _get_id function and step over, while
> using a bad csv file or directory.
>
> I'm not concerned that it kicks up a fuss about bad csv files and stupid
> developer symlinks and chucks an error, but that it is so difficult to
> recover after correcting - and I think the bug is more related to
> ir.model.data than csv import. Maybe just throw an exception if a
> hyphen is in the path.
>
> While I highly do not recommend this, if you want files to test, good
> files is latest rev of lp:~gdgellatly/openerp-au/l10n-nz-minima...