Extremely slow performance when editing articles w/ majority behind paywall

[ScottBarkman]

We have a rather large installation running with the majority of articles behind a paywall. (18,000+ articles) When this many articles have an access object assigned to it update queries on articles were taking upwards of 4 minutes to complete (and in some cases failing all together).

It appears that the access inline widget is gathering up the AccessObject result set, which in our case was ridiculously large thus stalling the save of the object. After poking around in the code for a while, I began to thing this was more of a default Django behaviour than an Armstrong built behaviour - but there still must be a way not to load up the entire result set when validating this widget.

Our solution for this was to override the Inline access form and adopt a much simpler "private/public" select box and to handle the date selection manually thus bypassing the need to generate the default access widget. This fits our needs well, however its limited to only us, as having the widget obviously adds value to Armstrong as a whole.

[crccheck]

Not sure if it goes in here or in your project, but would the raw_id_fields setting help?

[ScottBarkman]

Nah, I don't think so. The issue is with the standard access object inline that gets generated from Armstrong (through the AccessMixin) My understanding of raw_id_fields is just gives an easier way to attach a foreign key to an object which isn't really what's happening here.

Somewhere in the bowels of Django, the inline widget factory is requiring Armstrong to pass in the related model (AccessObject) - its here that upon saving an existing article, queries up the entire AccessObject result set only to, I'm assuming, check to see if the object already exists.