Patch for "fields" error.

2 views
Skip to first unread message

Robert Ramsay

unread,
Jan 9, 2011, 10:05:03 PM1/9/11
to rum-discuss
I'm starting a new thread for my error at the end of my previous
thread.

I found a work around:

diff -r bdb3dff87a61 rum/controller.py
--- a/rum/controller.py Fri Jan 07 10:02:18 2011 +0100
+++ b/rum/controller.py Sun Jan 09 21:57:03 2011 -0500
@@ -260,7 +260,13 @@
return self.view
routes_ = routes.copy()

- routes_['fields']=self.fields
+ if getattr(self, 'fields', None):
+ routes_['fields']=self.fields
+ elif getattr(self, 'obj', None):
+ routes_['fields'] = self.obj.fields
+ elif routes['resource']:
+ routes_['fields'] =
self.app.fields_for_resource(routes['resource'])
+
routes_.update(**kw)
self.view = util.adapt_call(self.app.viewfactory, **routes_)
return self.view

P.S You should update your documentation. 'session.transactional' has
been deprecated. In sqlalchemy 0.6 and up it's 'session.autocommit'

Michael Brickenstein

unread,
Jan 10, 2011, 7:26:44 AM1/10/11
to rum-discuss
Hi!
Thanks for the patch and the explanations regarding the autocommit and
transactional (I updated the documentation sources).

I am a little bit puzzled.

I got the same problem until I workarounded it with a strange
pseudo condition.

@call_action.around('my_true_function(1)==my_true_function(2)',
prio=400)
#use my true function to ensure order, that's ugly, prio alone
does not work
def _preselect_fields(next_method, self, routes):

It works for me.
I use peak.rules version PEAK_Rules-0.5a1.dev_r2659
Which one do you use.

I was a little bit tired on friday, but I checked several times now
that I indeed uploaded the correct code to PYPI.

So, thanks again for the patch, but the official version should
already work fine, and if not
I would like to make it working for everybody.

Might you alternatively try it with a snapshot of our repository

http://hg.python-rum.org/rum/archive/tip.tar.gz

Cheers,
Michael

Robert Ramsay

unread,
Jan 10, 2011, 10:57:09 PM1/10/11
to rum-d...@googlegroups.com
I think Peak-rules may have been the issue. I think pylons or I installed peak-rules-0.5a1.dev_r2600. I tested it with PEAK_Rules-0.5a1.dev_r3686-py2.6.egg (latest as of 10-Jan-2011), which also does not work. So I guess we must use r2659. I've attached the stack trace for when I try to delete.


--
You received this message because you are subscribed to the Google Groups "rum-discuss" group.
To post to this group, send email to rum-d...@googlegroups.com.
To unsubscribe from this group, send email to rum-discuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rum-discuss?hl=en.


delete_trace.txt

Michael Brickenstein

unread,
Jan 11, 2011, 3:48:10 AM1/11/11
to rum-d...@googlegroups.com, Robert Ramsay
Hi!

Thanks for the feedback.

Am 11.01.2011 um 04:57 schrieb Robert Ramsay:

> I think Peak-rules may have been the issue. I think pylons or I installed peak-rules-0.5a1.dev_r2600. I tested it with PEAK_Rules-0.5a1.dev_r3686-py2.6.egg (latest as of 10-Jan-2011), which also does not work. So I guess we must use r2659.

You can use the latest version of peak.rules, I fixed the problem and made the code clearer.
One might guess (although I don't claim it, that peak.rules recognized my tautology with constant functions).

The controller API is decomposed in single steps.
Since it is completely unclear which extension points we should provide here,
Alberto constructed it in some way, that each step has assigned a number (the priority).
While it might remember on ugly old fashioned line numbers,
I do not now any better way to make the controller API
customizable. In fact the factory-APIs look more inspired.

If you look at the priorities single steps, then it is sure, that he meant the priority
to be the argument which orders the call_action.around steps.

peak rules around functions are always ordered by implication/precedence.

So, when there are no different predicates than priority everything works fine.
However any additional predicates to be checked can disturb the order
as the priority of prioritized_methods only applies on ambiguity of the main predicates.

I refactored the code and pulled out all predicates to if-conditions in the call_action.around
functions.
So we can avoid such trouble in future.

http://hg.python-rum.org/rum/rev/22a78dd38e02


> I've attached the stack trace for when I try to delete.

I fixed the delete bug some days ago.
I am not sure, which version was on PYPI, so I just pushed a new release of tw.rum.

So,
easy_install -U tw.rum rum

should give you the necessary upgrades.

Many thanks for your feedback!

Cheers,
Michael

> <delete_trace.txt>

-------------------------------------------
Dr. rer. nat. Michael Brickenstein
Mathematisches Forschungsinstitut Oberwolfach gGmbH
Schwarzwaldstr. 9 - 11
77709 Oberwolfach
Tel.: 07834/979-31
Fax: 07834/979-38

Robert Ramsay

unread,
Jan 11, 2011, 8:08:52 AM1/11/11
to rum-d...@googlegroups.com
Thanks! I didn't realize the delete bug was in another module and I never updated tw.rum.
Reply all
Reply to author
Forward
0 new messages