Skip to content
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

No multi-process support #28

Closed
kevcampb opened this issue Feb 26, 2013 · 4 comments
Closed

No multi-process support #28

kevcampb opened this issue Feb 26, 2013 · 4 comments

Comments

@kevcampb
Copy link

It seems that django-select2 is dependent on two global dictionaries for the autoselect fields. The following are in django_select2/util.py

# Generated Id to field instance mapping.
__id_store = {}
# Field's key to generated Id mapping.
__field_store = {}

Obviously this is going to fail when you run multi-process. Not sure what would be involved in getting multi-process support, and whether these details could be written back into SQL. That may be a feature request, although breaking multi-process support is certainly a huge issue.

At the very least this should be highlighted on the front page of the manual, so people are aware of the limitation before bringing this library in.

@applegrew
Copy link
Owner

This was on my Todo list. Sorry for not pointing that out in Readme. You can still use this library in multi-proceses scenario if do not use Auto fields.

Let me checkout the options. I guess I will use memcache for multi-process support in Auto fields.

@applegrew
Copy link
Owner

Supported added in version 3.3.0.

@svartalf
Copy link

svartalf commented Mar 4, 2013

Shouldn't there be something more easier for unique ids instead of a this syncronization via memcache? I guess, python path for each of a autocomplete classes is unique enough and we can just use it for a field id.

I'm using that scheme and it works for me:
https://github.com/svartalf/django-select2/commit/60f707f775d211417c06865498268e40f47df78d

@applegrew
Copy link
Owner

The reason I chose the random id approach since that way no outsider (outside of server, a typical user) can guess the path of the field. Since field names and their paths reveal a lot of inside information so I consider that information sensitive.

Hashing the path too is a novel approach but they are not impossible to crack. However, I do recognize the fact that maybe for 90% of the users your approach would suffice. Particularly when that rids us of the need to use Memcache.

So, I will incorporate your changes and make that the default. The current random id approach will remain there which can be turned on if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants