[6.1] Installation error: maximum recursion depth exceeded

Bug #920367 reported by Stefan Rijnhart (Opener) on 2012-01-23
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenERP Financial Statement Template Reporting
Undecided
Unassigned

Bug Description

Hi,

after applying my tentative solution for lp:920363, I get another error.

  File "/home/oervwncrmdev61/bzr/openobject-server/openerp/osv/orm.py", line 573, in get_pg_type
    elif issubclass(field_type, (fields.char, fields.reference)):
RuntimeError: maximum recursion depth exceeded while calling a Python object

The problematic field seems to be account_fstr_category.progenitor_id, which is a function field of type 'related'.

Cheers,
Stefan.

Claire (cjin) wrote :

Hi, I got the same error "maximum recursion depth exceeded while calling a Python object"

Is there any solution for that?

Thanks

Claire

Jay Maniar (z3m-jay) wrote :

Yes, I am getting same issue of "maximum recursion dept exceeded while calling a Python object".
I think it is very useful module. Is there any solution for that?

Jeroen Vet (jeroen-vet) wrote :

Hi I managed to get the module work in 6.1 by making the changes of attached patch file.
Added advantage is that account_fstr can now also be used from the web client in 6.1!
Apply the patch by issuing the following command from a directory containing bot the old account_fstr directory and the patch file (linux):

patch -p1 < ./account_fstr_for_6.1.patch

and you are set to install the module in 6.1

Publicus: please apply the patch for a 6.1 version of your great module (it doesn't work in 6.0 but it can be easily made to do so).

Changed in account-fstr:
status: New → Fix Committed

Well done, Jeroen for solving this 'related function field' brainfuck. These unmaintained community addons are the nails in the coffin of OpenERP if it wasn't for guys like you.

As Enapps said, 'will be working on it soon' 7 months ago https://twitter.com/ColinMacMillan/status/161392937337503744.

Stefan, this is mean from you!
The whole point of open source is that people should contribute with bug fixes etc and not expect a company to take care of every single problem for free. We are running a business here, not a charity and as such will allocate our resources to revenue bringing activities and will deal with community bugs when we are not so busy.

Jeroen Vet (jeroen-vet) wrote :

Sorry guys, patch was not complete. When pressing the Preview button in the wizard things still didn't behave as expected. The attached patch should take care of this problem. Strangely, it the __openerp__.py file was not complete in that the report definition was not loaded. With this patch on the original module it should all work.

This patch should be run like this:

patch -p0 < ./account_fstr_for_6.1.patch

Hi Vadim,

Indeed, you are under no legal obligation to maintain the modules you published or to respond in any way to the bugs that are reported and I understand the business argument completely but it would still be good for the OpenERP ecosystem if you and other people would put a little bit more effort in the community.

So do not take my remarks too personal, please. Although I was a bit miffed with Colin not keeping his promise, I was also rejoicing the fact that someone like Jeroen can come along and make it work. That is indeed the power of open source and I was glad to see it working.

Cheers,
Stefan.

Jeroen Vet (jeroen-vet) wrote :

Still some problems with the view. OpenErp 6.1 does not allow use of icons in a hierarchical tree view. So view for displaying categories cannot be shared any longer. Created a new view for displaying the tree structure. Also reverted earlier change to __openerp__.py file. The report was loaded after all in another xml file. Attached patch should be the final resolution (I deleted the earlier patches).

Julian Olivero (julian-olivero) wrote :

Dear Jeroen,

I applied the final patch and to install the module, but its still giving me the same error
RuntimeError: maximum recursion depth exceeded while calling a Python object

i applied the patch as follows patch -p0 < ./account_fstr_for_6.1_final.patch

please let me know if i am doing anything wrong

Regards

Julian

Jeroen Vet (jeroen-vet) wrote :

Hi Julian,
the patch most probably did not apply correctly.
With regards to the recursion bug the relevant lines are in account_fstr_category.py which define the the function fields progenitor_id and progenitor_name of the class account_fstr_category. After applying the patch they should now read:

'progenitor_id': fields.function(_get_progenitor_id, method=True, string='Progenitor', type='integer', store={ 'account_fstr.category': (_get_childs, ['parent_id'], 1)}, multi=True),
'progenitor_name': fields.function(_get_progenitor_id, method=True, string='Progenitor', type='char', store={ 'account_fstr.category': (_get_childs, ['parent_id'], 1)}, multi=True),

the types have been changed from 'related' to 'integer' and 'char'; specifying 'related' is not allowed and causes the recursion.

I have attached the module with the patch already applied, so you can try with that.
Good luck!

Dear jeroen,

I tried to install with the package you provided and its giving me error again.

I am attaching the error that i get along.

It would be great if you could help.

Regards

Julian Olivero

Jeroen Vet (jeroen-vet) wrote :

Hi Julian,
Yes I know this error and it is exactly this error (and some other errors) the patched module resolves.
In order to try reproduce your problem, I downloaded the module from this page and installed it on a fresh database in 6.1. It installs flawlessly. The only possibility is then that you are still using the old code somehow.
Please remove the old module, put the new module in your addons path and try again. I don't know how else to help you.
Good luck!
Jeroen

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers