Re: Setting up jQuery in debian with virtualenv
On 9 November 2016 at 13:54, Gary Roachwrote: > I want to know how to use the pip installed version of the jquery file if > possible. you can check what the admin templates do. probably something like {% url "admin/js/vendor/jquery/jquery.min.js" %} -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRCbDuYz83-9Y1Apj%2BWCAbB5Qp1a8EuHXa%2BFj0vHJ6N9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Negative User ID's
On 4 November 2016 at 18:28, <mich...@zanyblue.com> wrote: > > Unfortunately, the apps are currently in different DB's. > > On Friday, November 4, 2016 at 10:26:34 AM UTC-7, Javier Guerra wrote: >> >> that's what foreign keys are for even so, a foreign key field is the answer. i see three different ways to do it: - on the app. just add an indexed (unique) field, with the id on the other DB table - with a 'ghotst' table, that is actually related to your Users model and some model methods to manage it - managed by the database itself. not sure about other RDBMS, but postgre at least have some serious "foreign data wrapper" capabilities that make many kinds of other things look like regular tables. [1]: https://wiki.postgresql.org/wiki/Foreign_data_wrappers -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRFAOBDC35dOFGWrBfScT%3DRGxH3xGykKQDkhYgnqgT_Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Negative User ID's
On 4 November 2016 at 17:17,wrote: > To support future integration, I need to ID's to be common across the two > apps. that's what foreign keys are for -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSKbdY4jabk4oQA%3DksB4zcxqQtrBJLKROR3NF4W_1E69Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Compressing images before saving to database
On 16 September 2016 at 05:45, Isaac Tettehwrote: > I have a project where users upload photos of any type. But i want to > compress the images before saving them. Is pillow the best i can use or Is > there a built in or 3rd party library to do this. Its link to documentation > will be appreciated too. I've used Wand (a binding to imagemagick library) on a background task, since I had to handle HUGE images -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQk%3DG95yRsyMdmRN%2BMOEJ5os15nLzo7AZwTYEk9YUYW-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Disadvantages of using model name rather than model class for FK field?
On 1 September 2016 at 11:55, James Beithwrote: > By using a model name there are fewer imports at the top of the module and > fewer occurrences of circular import dependencies between Django > applications. What are the disadvantages to using a model name and why not > always use them? totally a wrong reason, but i like using classes instead of names because that way it feels more "programming" and less "configuration". a _possible_ (but not really convincing) reason would be that it makes it easier for tools (syntax highlight, autocompleting editors, static analyzers...) to detect typos. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQhr%2BjVo5PRS%2B5x-0j88r-4VEafVk0Pz7Cg-foUsWX7Qg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Best way to keep the current selection
On 27 July 2016 at 02:02, Lee Hindewrote: > To maintain state, after any ad-hoc query, I store the ids for the found > records: > > self.request.session['query.classes.last_ids'] = > list(queryset.values_list('id', flat=True)) add a new model: Previous_Searchs or something like this, with metadata on the search (user, date, sort critera, etc) and a many2many link to the found records. it makes it easy to repeat a search, keep it for longer, name it, or even share it -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ7_0jHOFdoPUL3G6GizWvFZub354Vjcog-LTb3ZKQ8-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: deploy django with nginx
On 15 July 2016 at 11:47, 1351552...@qq.com <1351552...@qq.com> wrote: > and with the message in file /var/log/nginx/error.log : > connect() to unix:///home/wangwei/yaohang/yaohang.sock failed (13: > Permission denied check under what user is running nginx, and make sure that it has r/w permissions on that socket -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ8WW-JS-pKLz4SN8QNp0e%3DQGUjg0pOVvXsKsGNc0mNig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Document storage and data mining
On 15 July 2016 at 00:02, Gary Roachwrote: > While - with the exception of the metafile - these are static files, we are > talking about hundreds of documents. I do not think that storing them as > static files will work. They have to be searchable. I assume that I need a > model that will set up appropriate fields in the database (postgresql) This > is where I stumble. I've looked at the Model.field reference but can't seem > to come up with what I need or don't know what I'm looking at. The latter > being the most probable. do store the PDFs as static files. just not in a single directory, instead add one or two levels of subdirectories. Alternatively, use an Object Storage, like S3, for that (check django-storages [1] for an easy way to do it). To make them searchable, store the plain text of the document in a TextField in the model, and add a full text index (you can use Watson [2] to help with that). [1] http://django-storages.readthedocs.io/en/latest/ [2] https://github.com/etianen/django-watson -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ0WCe48gDP-atcLBLD4TsrA9%2BczAtSAPiD6%2BCaHijiSQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: resetting table id (SOLVED)
On 4 July 2016 at 01:09, Gary Roachwrote: > All of this drove home the fact that db.sqlite3 is no more than a text file > and can be thrown away and recreated any time I like wrong. SQLite keeps the database on a single file, but its nowhere near a "text file". you did truncate to a single byte ('\n', added by default if you don't use the '-n' option on echo), and it had to be thrown away and recreated. it would've been 'nicer' to just delete it. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT13BWnXTv0KNfGtEpRLqQobZ9Hbi_yzbzz8hi7-yVaZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Making queries with custom SQL
On 16 June 2016 at 16:21, TheBeardedTemplarwrote: > I'm using postgreSQL and have found that recursive queries are exactly what > I need In most cases it's much better to use a more efficient form of tree. A common one is called MPTT, for which there are Django packages. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS6Lsqe5173-1GZ%3D3c9hOqStice3DTqqEEEP84ua2QSLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: sub accounts in django
On 18 May 2016 at 17:02, Mehdy M. Haghywrote: > Creating sub accounts is a pretty common scenario. > you have clients like (copmany1, company2, ..., company N) > and they have their own users, roles and permissions. > any recommendation on how to implement this or any package recommendation? that's commonly known as "multitenant" applications. there are several approaches to do it, and quite a few packages to help with either. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR16k5PuPzT6bf178%2BKRnjsvsDinDUk7vnRRzrMPvaU5Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: MTV and MVC difference
On 19 April 2016 at 12:53, Mukul Chakravartywrote: > What is the difference between Models in django MTV architecture and Models > in rails MVC architecture ? IMNSHO, mostly about the realization that "controller" (as defined in the original, GUI-oriented formulation of MVC) doesn't have a place in every web application. In a very concrete sense, the best place for it is the framework itself. So that leaves us with just models and presentation. But the presentation is best split in a data-gathering function and a non-turing-complete template; so now you have Models, Views and Templates. Note also that Django Views are typically much thinner than MVC views. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTGQCJSW68Dx8km13PuyUEyiiLQi%2BHUi11ufCsEhs-DMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Question about users system
On 15 April 2016 at 12:17, Eduardo Leoneswrote: > I am developing a system in which my clients are companies. Every company > needs to have its isolated from other business data. google for "multi-tenant" web applications. warning: there are quite strong opinions about how it should be done. in particular, there's lots of advice of setting a separate database for each tenant. It does have some advantages, but in practice it's not easy to do in Django. > My reasoning is to register each client (company) as a group within the > Django auth system. Users of them would be users connected to this group. Yes, this can work. Personally, instead of reusing the Group tabke, I tend to create a specific 'Company' table, and add a 'company' foreign key to users. The reasoning is that you _will_ have other groups that are not companies (maybe internal divisions, or for access-level privileges, whatever), and then you have the problem of separating two kinds of groups. > This line of thinking is correct? There is a decorators to limit access to > the Group as a whole? In part of the Model link the data to a group is a > good practice? Make sure that every record can be traced to a specific Company, some of them because they're linked to a User, or maybe by a direct 'company' link. Then be _absolutely_ sure that every database query includes a company condition. something like this: @login_required def getsomething(request, id): thing = get_object_or_404(Thing, department__company=request.user.company, id=id) build response ... It's tempting to put the "current" company somewhere and patch all requests to include that, but it gets very complex quickly, and also you get the problem of managing what in effect is a global variable. not worth it. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRFnNY_jaMx%2BkwOuUaXivkMJm2zptCiExunDf6qjKGXeQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Debugging DJango app on production for High CPU Usage
On 24 February 2016 at 13:18, Avraham Serourwrote: >> sometimes going beyond 100% > > how?? if it's what top reports, 100% refers to a whole core. a multiforking server (like uWSGI) can easily go well beyond that. and that's not a bad thing -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT0KnSKcFJ9wM03p2bWUxK1M3bQSW0oJNL_Zik-zvp7ZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Why does Django allow Circular Model Relation
On 19 February 2016 at 13:00, Eddilbert Machariawrote: > Hello All, > > I was working on a project, and realized that Django does not complain when > you create Circular Model relationship even when creating migrations where i > expected to have this complain why would it complain? it might be (sometimes) less than optimal, but it's valid to have circular relationships. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQJdgY8W%3DT7npsTmiyAipq4cP4oGqv6Q6mDW%3D%2B-PNp1qg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django deployment
On Fri, Sep 18, 2015 at 4:51 PM, monoBOTwrote: > The guide Mario Gudelj shared is probably the best you can find on internet. (the best if you like gunicorn) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTDzMrhKyMXFaC7rVESM4jWXHoDC5zWo26ujf%3DDocjAXA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Prefetch() with through models
On Thu, Sep 17, 2015 at 2:07 AM, Erik Cederstrandwrote: >> Den 16/09/2015 kl. 16.45 skrev Mike Dewhirst : >> >> On 16/09/2015 9:53 AM, Erik Cederstrand wrote: >>> issues because the prefetch query does something along the lines of >>> "SELECT ... FROM lesson_subjects WHERE lesson_id IN >>> [insane_list_of_lesson_ids]". >> >> I'm no expert so I'm wondering if len([insane_list_of_lesson_ids]) == >> "hundreds of thousands"? > > In my, case, yes. I think the backend might process the query in chunks if > the length of the SQL exceeds the max SQL query size. Just curious, which RDBMS are you using? I remember that on MySQL there used to be an advice to populate a temporary table and do a JOIN instead of very big `xxx IN ()` statements. I'm not sure if there's a hard limit, but anything over a few hundreds would be better with JOIN than with IN(...) With Oracle, there _is_ a hard limit, and a not very high one. I've hit it frequently when doing exploratory SQL on SQLDeveloper. For anything over a thousand items, it's safer to go the temporary table route. The only one where I haven't been able to hit any limit is PostgreSQL. There i routinely do many thousands of items and it works beautifully. I haven't personally tried "hundreds of thousands", but I guess that if it fits within some maximum textual representation, then it will handle it. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSAwPF%2BuajdhGLLROSW8p%2BkfrOnKLN91DUujxH7BRFEQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Angular.js advanced tutorials?
On Fri, Sep 11, 2015 at 5:03 PM, ThomasTheDjangoFanwrote: > I am searching for an angular.js tutorial that shows me how to do some > enhanced ui stuff: i think both angular and react are oriented primarily not to "enhanced ui", but to whole frontend applications. with that in mind, you'll find that most examples and tutorials treat the server either as an API provider (typically REST), or tightly cohesioned with the frontend (as is with meteor and some other JS frameworks) of course it _is_ possible to use either for enhanced ui, just don't be surprised for the lack of examples, and the feeling that you're killing flies by swinging a big couch. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQg9Mm41LMCmvmb%3D0BfK8By5r8sLnrqaLEqGDSO6y44oA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What frontend-tools to use for a new CRM project? Shall I use Django OR switch to Meteor.js?
On Wed, Sep 9, 2015 at 9:32 AM, 'Tom Evans' via Django userswrote: > We have (different!) django projects using react, backbone and > angular. and lots more! i've found riot.js a very refreshing foundation for those of us that hate JS. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTjEO91-AF%3D2Cm2xPnLW1OfwgdAx7a08q5CZg6E-zEr6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Serving uploaded files from multiple storages
On Tue, Aug 11, 2015 at 6:17 PM, 'Hugo Osvaldo Barrera' via Django userswrote: > I've an app where files are uploaded to differente storages: i would create a new storage object with a configuration that associates some prefix with other 'backend' storage objects. then implement each storage method by stripping the prefix, using it to determine the apropriate backend, and calling it with the rest of the path. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTMnMS9egF3Mvvs1%2B%2B1tw-Khsn3BP-_VR1N-O0wLeqqEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Invalid syntax in url.py
On Thu, Aug 6, 2015 at 2:03 PM, Matthew Yankeywrote: > url(r'^', .newsletter.views.home, name="home") .newsletter looks like import syntax, but this isn't valid in an expression at the top include a line like from .newsletter.views import home and then the url entry becomes url(r'^', home, name="home"), -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRG9nO6pkNur23saV7EdpcK_Cnu1Mc7F%2Bg5h_tQMWLKRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: how to descript the many to one relationship in model when there are more than 1 tables
On Thu, Aug 6, 2015 at 8:18 AM, Holland_zwzwrote: > But i am not got the main point. The problem is the table C's oid column > data comes from A or B. I don't think SQL works that way. at least, it's very much against any normalization guideline. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTpXwxL3vpGxxF0nH%3DZjV8pk7db1sC69b6PVNn7CZ6QDw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Using django as a socket server and not HTTP server
On Wed, Aug 5, 2015 at 10:14 AM, Idan Shimonwrote: > Hi i am interested to setup my own socket protocol against a peripheral > device > The socket server would be online and exposed to the web, however it will > not work on http. not as it is currently. the issue is that Django is a WSGI app, and Nginx doesn't pass TCP connections, it parses HTTP and passes it to the Python stack (via FastCGI, uWSGI, HTTP, etc). Even if the backend connection is HTTP, it's a "reconstructed" http after being interpreted by the frontend. if your protocol is not HTTP but it's roughly request-response, then you might be able to create a frontend that calls Django (or any WSGI app) in the back. Maybe by hacking gunicorn, or creating a uWSGI plugin, or using the new async capabilities in the latests Python versions... but it would be the current stack as is. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS5CHn_dGc6-0QjOkqD-6JMqxMdoe5VGoRUE3VJFcDmpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: same field in two classes
On Sun, Aug 2, 2015 at 5:54 PM, Robin Lerywrote: > You can use inheritance. Or content type. Or use signals to get the value of > salary from one model and save it to another model. or choose the right place to store it and don't duplicate information. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQax6rdctpAAs1Qy4SHhxDdetPXZ%2BPdt0VNoKTeqnO3Jg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: DB Design question
On Sat, Aug 1, 2015 at 4:53 AM, James Schneiderwrote: > If you are talking about potentially having enough rows to extend past the > AutoPK limits, you should consider instead using a UUID field as the PK: note that this is only good advice if your DB handles it natively. if not, Django will use a charField to store it and constantly encode-decode it. If you're using PosgreSQL, then yes, UUID is great; on MySQL, then it's far more efficient to use a BigInteger. 2^64 records still is far more than what you can store in the biggest storage you can get. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRzx3m%2B4rYuppJw_hWtt552tVG769B67RuOj8EdJCrQsg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: One-time tasks at varying times with Uwsgi Spooler
On Fri, Jul 31, 2015 at 7:26 PM, thinkwellwrote: > a_long_task.spool({'hello':'world', 'at':timedelta(hours=5)) the 'at' parameter should be _outside_ the callable dictionay, and it must be the unix timestamp, not a timedelta: a_long_task.spool({'hello':'world'}, at=(datetime.now()+timedelta(hours=5).timestamp()) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRb1atmAYFafHBrPC%2BNYdVO0T%2BY%2Bf5v3tHZ821PVXG5Ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: How to save data from form FileField to DB Django
On Thu, Jul 30, 2015 at 10:40 AM, user07285wrote: > I have a model and have added a Form FileField to take a file and save all > their contents for a particular object. The FileField doesn't need to be in > the database hence not added as a model.fileField. The content from the file > should be read , parsed and added to the synonym_type. first of all, it's almost always a _terrible_ idea to save files in database fields. Yes, it works, no, it's not "faster"; it creates a heavy overhead on an already sensitive part of your system. but, if you want to do it, the easiest way is to use a Storage Object that manages the saving and thus you can keep the FieldFile abstraction (either from a FileField or a File() object). Even better, when you get to migrate to a different (better!) storage, you only have to modify the settings and the code can stay the same. check DjangoStorages [1], it includes a "Database" backend [2] (and other like S3, libcloud, etc) [1] https://django-storages.readthedocs.org/en/latest/index.html [2] https://django-storages.readthedocs.org/en/latest/backends/database.html -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR4JMENcuHmTBxJApEG_nMC8sUCs92n%2B4QJ6iixckF8Vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Testing related models without saving
On Thu, Jul 16, 2015 at 8:18 AM, Roland Swinglerwrote: > I understand that the test db uses a different schema (it's the same in > rails), the point is to be able to run tests isolated from having a database > at all. there are several testing styles, each one with different dogmas. discussions of the adequacy of them can get very heated and non-productive. one of these styles states that each test should be perfectly isolated from any other conceivable source of errors, including the database, and in fact stopping short of suspecting the base OS itself (usually). without trying to get too deep in religious dogma, i'll just say that Django tests don't favor too much into the "unit" test spectrum; instead they lean somewhat towards the "integration" camp (although not totally there, either). in short, the database is considered a required infrastructure service, and tests usually assume it works as expected. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR08cr5DSFH9HOXXxXvdH2QwefE-xuO0yi8hDmf58bSNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django formset hidden id field
On Sat, Jul 4, 2015 at 1:42 AM, Peter of the Norsewrote: > You can’t have it both ways. Either exposing the PK is a security flaw or it > isn’t. It’s just as easy for nefarious n’er-do-wells to edit the form’s URL > as a hidden field. In either case, if you are using object-level permissions, > more checks (not made automatic in Django) are necessary. Having the ID > passed as a parameter doesn’t necessitate, hinder, or alleviate running these > checks. the easiest way to make forget PKs a non-issue is to never do things like: myobj = MyModel.objects.get(pk=pk) instead, do things like: myobj = get_object_or_404(request.user.accessible_obj_set, pk=pk) where the 'accessible_obj_set' is either a reverse foreign key, or some method that returns a queryset with apropriate filters to return only the rows that a given user can access. > If you can come up with a method that associates form data with a database > row that doesn’t involve the PK, I would love to know. Keep in mind that most > tables only have the one unique identifier. there are many fans of using UUIDs as primary key. myself, i use them for any user-visible record when there might be several instances of the same code. this way i can merge or split datasets without changing user-visible references. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTHDBgK2v5Po09cShjQt7VoipA50BcoqawP6MymMmk1uQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Help me develop a Job Tracker (?)
On Fri, Jul 3, 2015 at 2:50 AM, Softeisbiegerwrote: > Thanks for your input! Indeed, a linear pipeline should be sufficient. What > do you think of my idea of organizing this in two database tables? One table > models a work flow. A work flow points to the currently active task in > another table. Each task has information about its predecessor / successor. > In principle like a doubly-linked list. This solution feels a bit brittle / > hacked to me. Again, my reason is, I want to store all the work flows with > this standard interface. Also, users can easily create new work flows with > any number of steps. Maybe there is a better way? i don't think a linked list is appropriate for databases. the simplest design would be: a Workflow model to identify it (with id, name, creator, that kind of things), and a Step model that 'belongs' to the Workflow something like this: class Workflow(models.model): name = models.charfield() class Step(models.model): workflow = models.ForeignKeyField(Workflow) name = models.charfield() order = models.SmallIntegerField() taskdescriiption = models.TextField() class Meta: ordering = ['workflow','order'] def previous(self): return self.workflow.step_set.filter(order_lt=self.order)[-1] def next(self): return self.workflow.step_set.filter(order_gt=self.order)[0] those two models keep the definition of a workflow. then, define the 'working' models, one for a whole project, and other for each task to perform: class Project(models.model): name = models.charfield() workflow = models.ForeignKeyField(Workflow) responsible = models.ForeignKeyField(User) deadline = models.DatetimeField() def started_tasks(self): return self.task_set.filter(start__isnull=False) def finished_tasks(self): return self.task_set.filter(finish__isnull=False) def in_process_tasks(self): return self.task_set.filter(start__isnull=False, finish__isnull=True) def finished(self): return self.started_tasks.exist() and not self.in_process_task.exist() class Task(models.model): project = models.ForeignKeyField(Task) step = models.ForeignKeyField(Step) deadline = models.DatetimeField() assigned_to = models.ForeignKeyField(User, blank=True, null=True) start = models.DatetimeField(blank=True, null=True) finish = models.DatetimeField(blank=True, null=True) in most cases, it's better not to have a 'current task' pointer. just some tasks that have been started but not finished(yet). it's up to you to decide if it's appropriate to have more than one task in process for a given project, or if it's valid to start a task before some of the previous tasks. usually it's also nice to add action methods to some models, maybe a project.start(user) that creates the first task and starts it, and a project.next(user) that finishes a task and creates/starts the next one (if there's any more step(s)). -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTOXLOiSM0ctV%2BBWaPjSp24qv4QF5Ux0ZwsaZ90wLb3vA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Help me develop a Job Tracker (?)
On Thu, Jul 2, 2015 at 10:26 AM, Softeisbiegerwrote: > I am currently thinking about the database representation. I don't think I > can solve this with django-viewflow: I need to be able to specify in advance > a deadline and an assignee for each task of a work flow. first of all, its important to note that a full-featured workflow engine is Turing-complete, so it's theoretically undecidable. There are limits on what kind of tools an automated system can provide. specifically, it's easy to write workflows for which it's impossible to calculate a detailed schedule. if you want your system to be able to define deadlines for each task given a final deadline, or some useful "%-done" indicator, then you might be better served by a "limited shape" workflow model. The simplest case (yet widely used) is a linear pipeline of tasks, which can look similar to what you describe. with a linear pipeline, it's easy to set time estimates for each step, to calculate proposed milestone dates backward from the final deadline date. If you get behind schedule, it could even estimate "tight goals" by proportionally distributing the remaining time between the remaining tasks. some limitations of the linear model can be relaxed by defining some steps as "optional", or allowing some authorizations to skip a task, or by specifying the prerequisites of a task as not necessarily "all the previous steps". if you still want the wide flexibility of a full-featured workflow engine, recognize that it's not easy for most people to think in terms of abstract states, and planning all the interdependences between steps of any slightly complex process is in fact a programming activity, even if done graphically. IOW, if you ask users to repeatedly one-shot workflows, they will naturally limit themselves to simple lists of tasks and manage any unexpected circumstances by (ab)using 'override' permissions. workflow engines shine if you have a mid-to-large group of people doing some complex process repeatedly. a good example (and one where i've found them quite a lifesaver) is in the publishing industry: you have several editing steps, with well-defined approval points, and rules of when some work must be redone, discarded, or rushed. and it must be done again and again, for each campaign, so it pays up to do a very detailed model. note that a state-transitions diagram is usually drawn as several circles connected by arrows. The tasks are associated to the arrows (transitions), not the the circles (states). Also, in most engines, each transition has some permission restrictions and maybe a way to specify preconditions, which makes it easy to show, for a given user, which are the transitions available for a specific process. good luck! -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS3bC6NZUYD%2Bu6D00g67tKSfH6vcJhwKv0a6R_Vd%2BdTZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: How To Activate Django Server.
On Fri, Jun 26, 2015 at 4:56 PM, Steve Burruswrote: > I AM able to create a new virtual env. but I gfet this error message when I > try to create a new project! have you installed django in this virtualenv? -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTqQ26wA9up0mTA1Y0A7UHKC-cKWXwBCA%3DBAoUscSTRCw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: help with e-library
On Fri, Jun 26, 2015 at 6:55 AM, Mane Saidwrote: > where is the best place to start definitely, the Django tutorial. your project sounds like a very straightforward database application. after finishing the tutorial you might easily model your concepts, or you can always ask specific questions here. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTTapqY41Endx-Mr5EAxy185x%3D3JbfRBY9KMosLpcuQ7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Help me develop a Job Tracker (?)
On Fri, Jun 26, 2015 at 3:01 AM, Softeisbiegerwrote: > I am uncertain how to handle different work flows, though. The user should > be able to define these 'on the fly' and I have no idea how to express this > in terms of django. What I know about a workflow: there's a thing known as a workflow engine, with extensive theory, definitions, terminology, research and implementations. Check some of theory in wikipedia[1]. as is common in Django, a very useful first stop is djangopackages.com, where you can find a comparison grid of workflow engines already created for Django[2] some of them are quite capable, and even if miss something you would like, they're not too hard to adapt, once you have the theory well understood. Of course, if you're new to Django, first you _have_ to do the tutorial, or lots of things might not make sense. [1]: https://en.wikipedia.org/wiki/Workflow_engine [1.1]: https://en.wikipedia.org/wiki/Business_process_modeling [1.2]: https://en.wikipedia.org/wiki/Petri_net [1.3]: https://en.wikipedia.org/wiki/Kahn_process_networks [2]: https://www.djangopackages.com/grids/g/workflow/ -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRU5qqhQrdSmSfeE3KJzCxxd6icqEdahp9uQ6GnL-HSBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Scaling/Parallel patterns for a View executing complex database transaction
On Sun, Jun 14, 2015 at 3:13 PM, Peter of the Norsewrote: > Almost all of them are faster at key/value returns than PostgreSQL. i seriously doubt that. most "fast" key-value databases are only fast if you either: keep all data in RAM, forget about durability, or distribute the load on several shards while shifting consistency tradeoffs. know what? a good SQL engine gets faster too if you do any of these things. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQv3f2n8zCrNDgOHyENx2%3D7m1oNF9NHZ6sJ47dDdcOomw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: "&" string to template adds "" in the html
On Fri, May 22, 2015 at 1:11 PM, dkwrote: > I fixed doing this > > {% autoescape off %} > {{ my_var_with_& }} > {% endautoescape%} the "right" way is: {{ my_var_with_anything|safe }} -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQGBKY2YWarBgL9qg2BkHkZ%2BYybw74rJE0eaessr%3DEGkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Logout user on tab closing
On Tue, May 19, 2015 at 8:23 AM, Miloš Milovanovićwrote: > I want to logout a user from application when the application tab is closed. the browser doesn't notify the server when the tab (or window) is closed. remember that the original web architecture was simply about downloading HTML documents and showing to the user. Once the download has happened, we're done with the server. the whole concept of "web application" is javascript running in the context of a web page, so you need the application itself (not the browser) to notify the server. You can use the "on-unload" event; for example with jQuery's .unload() event hook. Note that this event fires every time the page is unloaded, not only when the window or tab is closed, but also if the user navigates to another page (either via the URL bar or by clicking any link), uses the 'back' or 'forward' buttons, or even when reloading. that's why most web applications rely on timeout and not on trying to detect the user leaving the application. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQumw7hWa6DKL-WTAx%2BLyjWciMCgxuBDyC2H5HB_kBGdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Embeding HSQLDB in a standalone App
On Tue, May 19, 2015 at 6:49 AM, Kapil Solankiwrote: > I need to embed hsqldb in my project. I have been looking for solution > online but couldnt find a proper one. AFAICT, hsqldb is a Java library, you need a Java program to call it. Maybe it's possible to call the JVM from Python... or write a standalone Java program and drive it from Python... not what i would call "a proper solution". the cleanest solution seems to be doing your project in Java. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSEcyc4MoK1Vpkvq3%3DCH%3DHZ4%3D7brN0Vu9YdkS2E3pQTjA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Multiple databases
On Mon, May 18, 2015 at 7:35 PM, Roger Dunnwrote: > The use case is that the normalized data will be fetched often, is very > tabular in nature, and the additional data is more document centric and will > be fetch less often, by quite a margin. have you considered PostgreSql? it does handle json or xml documents quite well (in fact, arguably better than most "document databases" out there) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS3rZwDOE%2BcMoE5V_VKz19nTA-jZj28QDicDEn_GkMepg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: The best way to mock querysets
On Fri, May 1, 2015 at 5:17 AM, Avraham Serourwrote: > In my opinion you shouldn't, you should set the test data and make a real > query then compare results, you shouldn't care how the function got the > data, but that it got it correctly. that's part of a much bigger religious war, with "unit tests" at one extreme and "integration tests" at the other. even without aiming for unittest purity, the "test only the code you're testing" idea would clearly advise for mocking the database. of course, that means many more tests for the database layer itself, which in turn make the OP's wish for quick tests all much more important. but when doing TDD, the favored tests aren't necessarily of the unittest variety; they lean somewhat more towards functional tests, almost integration tests. IOW: if it's a requirement for the code to work decoupled from the database, then test it in isolation. if not, then the minimal test (and minimal code to pass it) is to assume the database layer is already well tested by the framework (and it is!), and you're free to assume it in the tests. cheers, -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR2nsDrqmEWmTGnKqbaEoci%2BoJ-%3Dy%2Byg2vdP6vue3ssdg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django runserver needs restart on psql data changes
On Wed, Apr 29, 2015 at 12:35 PM, Arnab Banerjiwrote: > The rendering happens perfectly, but the problem is - when the client user > does a browser refresh, the new data does not get reloaded until I restart > the runserver. Is there something I am doing wrong with respect to getting > the data from the database and into my view? sounds like you're storing that data in a variable. you should either read it from database on every request, or get some cache invalidation techniques. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTY%3Dfxx7RHRKjjJsHJaAvUJoDtL1fS1-dgM2MeifsaVjg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations During Development
On Sat, Apr 25, 2015 at 12:28 PM, Timothy W. Cook <t...@mlhim.org> wrote: > On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez <jav...@guerrag.com> > wrote: >> if you don't store migrations, then you have to generate them on each >> production update, right? if so, wouldn't they count as untested >> code? how about manually tweaked, or data migrations? > > That will certainly be true once you start using a staging or production > server. > But before they they are just a kind left over creative ideas. :-) Not > really useful for anything in the future, AFAICS. South used to have a feature to "flatten" migrations (i never tried it, so don't know exactly how that worked). maybe a middle point between "don't save, generate at each server" and "save everything, get the same whole story everywhere" would be to do this before commit (or before merging to trunk): - revert migration directories to the currently deployed point. - revert development database to the same point (maybe pulling the current schema from production/staging) - make (and test) a single migration - commit everything. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRupubbCuQZo2qpJpX254c3-EBxo1_uysd1Pz08Q_Yd6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations During Development
On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cookwrote: > > On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt > wrote: >> >> Are you using version control like GIT? I save the migration folder with the >> __init__.py in GIT, nothing else, because al the migrations will be diferent >> in the diferent servers. >> > > This is probably what I should have done. I have been saving them all to the > git repo. with South i used to save them to the repo too and push whole to production. haven't tried Django migrations yet; is there any difference that make this more appropriate? if you don't store migrations, then you have to generate them on each production update, right? if so, wouldn't they count as untested code? how about manually tweaked, or data migrations? -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQyMXezXObEV7cMrG3AvPak82HQ8WBc_LXp-dc4pCi9gQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Concept of partial views to be resolved from other views or template tags
On Sat, Apr 25, 2015 at 3:11 AM, Stephan Herzogwrote: > I like that approach because it leads to any partial being a separated piece > of logic that can be tested and developed on a dedicated url. If necessary > it can be wrapped in a templatetag, which makes it easy to use from the > template layer. you might be interested in ESI (edge side includes, (partially) implemented by Varnish [1]) or SSI (Serve Side Includes, as done by Nginx [2]). they allow you to describe the 'assembly' of HTML in the front end, using several fragments retrieved from the backside server (Django), each one cached independently. not only you get modularity of code and testability as you describe, but also avoid the overhead of assembling everything in Python. you get more URLs and each request could potentially multiply by a sizable factor, but you get to easily cache complex pieces that stay constant even if other parts are more variable, or constant on a different variable... [1]: https://www.varnish-cache.org/docs/3.0/tutorial/esi.html [2]: http://nginx.org/en/docs/http/ngx_http_ssi_module.html -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTkfnjyOT0LRnPGZpFT6eEm7L%3DgL%3DMZ0%2BXeD7U5b7xYcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Model with two e-mail fields uniques
On Wed, Apr 8, 2015 at 12:18 PM, Luis Záratewrote: > > if you know that only have two emails for user and you check his email a lot > then the cost of join in time and machine resources increase innecessarily "normalize until it hurts, denormalize until it runs" here the OP is way, way, behind of the very first normalizations. any consideration of an hypothetical "cost of join" would be much later, if any. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQdCZQAiyo4N5781f8eTANOSOOJUwVQs2yTjj5GFFiCng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Model with two e-mail fields uniques
On Tue, Apr 7, 2015 at 2:20 PM, victor menezeswrote: > What would be the best way to make a model with two e-mail fields uniques? I > was thinking about writing some validation in the save() method but would > like to know whether Django has some built-in way to deal with it. it's a very bad idea to have plurality by adding a number of similar fields. instead, you should have a related table class Person(models.Model): first_name = models.CharField(max_length=100) last_name = models.CharField(max_length=100) class Email(models.Model): person = models.ForeignKey(Person) email = models.EmailField(unique=True) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTruUKGUxS0nKn6zyQFCy%2BY%2BY%2B4-kOBTOAgwOWQHR5AtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: newbie question
On Wed, Mar 18, 2015 at 9:41 PM, VMDwrote: > I have skimmed the tutorial and didn't find (notice) the answer. Why not > point me to an answer to my question? that's exactly the point. your question assumes Django works in some specific way, and there should be a simple answer for a simple need. but i don't think you assumptions are correct, if you knew how Django (and frameworks in general) work, your question might be very different, and the answer much simpler and better in general. really, doing the tutorial is a very good investment of your time. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ0MOT57JCKfTjxWn6CkypeP2POm%3DF90Vn%3DF88dYDDQdg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Future for Django, Jobs, Confused :/
On Wed, Mar 4, 2015 at 5:40 PM, François Schiettecattewrote: > commit to learning a new one every couple of years (or more often if you can). this. even if I write Python as a requisite when hiring, I expect any new recruit to be able to pick languages as needed. Of course, that doesn't mean we're jumping all around, just that the languages must be tools not barriers. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQxLm3s49B73%3D4g5zNQv65und0xvRS%3DgizDWWAw3MdVDQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django sometimes shows partial (incomplete) json data in production env
On Mon, Feb 23, 2015 at 11:54 PM, George Mejiawrote: > > Besides, this only happens on production env ... The code is fine and works > on production env, and the behaviour was normal before ... this also happens > for others queries (all only in production), I wonder what is cutting > conexion ? if so, when this occurs ? check the time needed to generate that response. this sounds like some serve-enforced timeout. (why to send textual data as a picture??) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTTU%2B75G1uUMmK5Uhq-i4QOuYTKBgtUeMGSx52uzJu_fA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Using class based views.
On Tue, Feb 24, 2015 at 1:51 AM, James Schneiderwrote: > However, if you have working view functions, what is the"need" to switch to > CBV's? this. the switch to CBV, wasn't "modern Django views are classes instead of functions; Get rid of your functions!, FBV are dead!". Instead it's just that _generic_ views weren't useful enough, and to make them more extensively configurable, they were transformed into a very capable, albeit complex, set of classes. all this is just for the included generic views, for your own views just do whatever you find appropriate to structure your code and, in the end, present a callable to the url() routing structures. If you have too much repeated code, by all means factor it out; either into supporting functions, or turn your views into objects, or classes, anything you like. But even if you decide to do some CBV, there's no need to use the included classes, as they're unlikely to be the best answer outside of the 'generic view' envelope. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR%2BPhV5mEAG%3DGWVnqcyRJbLBJ%2BnQUXdRJujED6RdKF-2w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Restrict downloading files in Django?
On Sat, Jan 31, 2015 at 11:52 AM, Robert Rösslerwrote: > what is the best way to restrict downloading files only to authorized users? it's not hard to do if you manage the file downloading with a view. of course, file serving within Django is very inefficient, your webserver (Apache, nginx, etc.) is far more efficient at this. so, the solution is to write a view that looks like it's serving the file (after checking for authorization), but instead of actually serving, delegates the job to the webserver. check X-Accel-Redirect (nginx) or X-Sendfile (apache) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRu08gBCwDcicr4g9iktDMqYtdkXZUNUVQMJOMZRPj73A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Model to create forms
On Thu, Jan 8, 2015 at 1:03 PM, Collin Andersonwrote: > 2) Also keeping all the experiments data in only one table and getting all > the information for one experiment by finding all the row with the same uid > looks a little bit a time consuming process but for now we used the > bureaucracy plugin for the last six month and it doesn't look like it is > slowing down too much the response of the wiki so it might not be so > inefficient after all. Maybe it will scale badly. Here again any advice is > welcomed. > > Databases are usually good at this sort of thing. It shouldn't be a problem, > but might require some database tuning. this is what _relational_ databases are built for. if you have two tables, one for the description of the experiment (one record per experiment), and another for the statistics (one record per data sample, with a foreign key to the experiment record); then fetching the description of the experiment, plus all the related data will be much faster, simpler, more compact and all-around more efficient than having one table per experiment. databases aren't flat files, use them as designed and they'll perform very well. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSM-Q1Jec_2tE4zyhwt8s0x0-jwpNZCj8mCMVfV_fsgtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Two Django projects with common models and business logic
On Wed, Dec 24, 2014 at 11:18 AM, andywrote: > Thank you. Since it's only me that'd be using the apps do can I bypass the > 'deploy using pip' thing and somehow directly use it in my other projects? you could just set links or add to your `sys.path` list, but that makes it hard not to break one project when developing the other. a little better is to use your version control system, so now you have (at least) three projects: project A, project B and a common app, each on a different repository. each server would checkout not only the project-specific code but also the common app -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT22CdQ888CYTenDneuddJMe2yS4ChJ8S0rXV0a%3DYZOaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Two Django projects with common models and business logic
On Tue, Dec 23, 2014 at 1:22 PM, andywrote: > Now, both the projects have some models and some business logic common > between them. I don't want to duplicate the code and data which shall be > chaotic going forward. Also, I want the models and code (business logic) to > be in sync (when models/code is altered). encapsulate those models and code in reusable apps. and since Django apps are just Python modules, you can package and deploy them using Python tools like pip. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTywL3z53KcNWV-AbiPa-PQuNV%2BjBHRqP1y_GUtN-0mtw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Raw access to cache table
On Thu, Dec 18, 2014 at 6:20 AM, Erik Cederstrandwrote: > I'm using Django as a hub to synchronize data between various external > systems. To do this, I have some long-running Django management commands that > are started as cron jobs. To ensure that only one job is working on a data > set at any one time, I have implemented a locking system using the Django > cache system. there are many ways to skin this cat; one of them is doing it the Unix way with flock. In short, it's a command line tool that makes it easy to do "if i'm already running, exit now" in shell scripts. check the man page, it lists a few ways to do this kind of things. http://linux.die.net/man/1/flock -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTFuxQ-f564uWBd6S%3DPaO960nxRKNLkspqko5DujjhioQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django and SSL
On Wed, Dec 10, 2014 at 1:22 PM, pythonistawrote: > Is there a need for ssl if apache (https) and a proxy are between django and > the outside world. if they're serving Django with apache, they should be using mod_wsgi, in that case not only there's no more needs for SSL, there's no space for SSL between apache and Django. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRy%3DJUEd%2BxWaVOUK%3DjHmTSVXxVUeGmyyWSLCZbNSpH-YA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Need help with unique_together - on ForeignKey and Boolean field
On Mon, Nov 17, 2014 at 6:10 AM, ThomasTheDjangoFanwrote: > > How would you do this? Can you give me a hint? 4 different ways: - don't do it as a flag, add a 'defaultImage=ForeignKey(ProductImage)' to the Product class. - don't use False for non-default, use NULL. since two NULL values aren't equal, they don't trip unique restriction - don't use True/False, use an integer to give images some priority. #1 is default, the others get 2...n - use a partial index (supported by PosgreSQL and SQLite), it's not directly supported by the ORM, but you can simply add as an "ALTER TABLE CREATE UNIQUE INDEX ProductdefaultImage ON app_productimage (image) WHERE is_default_image;" at creation and forget about it. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT73y-ASkzeM_TGJXMA4UjydYjyq7m5dLoC3N7JjNkZsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: need precise advice before final decision on Django
On Thu, Nov 13, 2014 at 1:32 PM, Krishnakant Manewrote: > I guess it is obvious that I only need the view and template part here. and forms. they're often used with models (i.e. subclassing ModelForm), but that's not a requirement. also note that doing XMLRPC calls in view code will block the request/response cycle. in principle that would mean you need a good multithreading WSGI container, but maybe some good event-driven-monkeypatching platform can work too. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQiB-nZN_q62WJHMb93Y_sMJ0QyVN6sXPconosfq4FVpw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Do you think Django's future is threatened by JS frameworks in both client & server?
On Wed, Oct 29, 2014 at 1:11 PM, Glen Jungelswrote: > the javascript frameworks (Node, Angular, etc) differ in that the execution > is done client side Node.js is a server framework. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRCgsCoCkwAFBzTY_ukVxpUe%2BN8iZW9yWOwEHUxeFVZmA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django builds incorrect sql-query
On Mon, Oct 20, 2014 at 3:43 AM, Алексей Широковwrote: > Javier, I am unable combine 2 parameters in a single call filter(), because > It is built on different levels of code. > > Is there another solution??? you can build up a dictionary and expand as parameters on a single filter() call: params = {} params['sendings__user']=1 .. params['sendings__state']=0b001 .. qs = Document.objects.filter(**params) i think you can also use a Q() object, but i'm not so sure about the exact 'simultaneity' behavior. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTYGTkFNrM1Ncuw3OJQU5V_5pZ8zfAke0mB%3DUhZGvk_%2BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Django builds incorrect sql-query
On Mon, Oct 20, 2014 at 1:53 AM, Алексей Широковwrote: > SELECT ... > FROM "document_document" > INNER JOIN "document_sending" ON ("document_document"."id" = > "document_sending"."document_id") > INNER JOIN "document_sending" T4 ON ("document_document"."id" = > T4."document_id") > WHERE ("document_sending"."user_id" = 1 >AND T4."state" = 1) > ORDER BY "document_document"."created" DESC > > Why...??? > it is incorrect!!! > > must be... > > SELECT ... > FROM "document_document" > INNER JOIN "document_sending" ON ("document_document"."id" = > "document_sending"."document_id") > WHERE ("document_sending"."user_id" = 1 >AND "document_sending"."state" = 1) > ORDER BY "document_document"."created" DESC >From the docs [1]: "To handle both of these situations, Django has a consistent way of processing filter() and exclude() calls. Everything inside a single filter() call is applied simultaneously to filter out items matching all those requirements. Successive filter() calls further restrict the set of objects, but for multi-valued relations, they apply to any object linked to the primary model, not necessarily those objects that were selected by an earlier filter() call." in other words, your query is equivalent to: Document.objects.filter(sendings__user=1).filter(sendings__state=0b001) here, `sendings__user` and `sendings__state` appear on different `filter()` calls, so each can refer to independent `Sending` objects. try: Document.objects.filter(sendings__user=1, sendings__state=0b001) in this case, `sendings__user` and `sendings__state` appear on the same `filter()` call, so they refer to `user` and `state` fields of the same `Sending` object. [1]: https://docs.djangoproject.com/en/1.7/topics/db/queries/#spanning-multi-valued-relationships -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRsD0ZAT4dp2UKu58SH2RC_rYL_s-VW6xV_HRXJTvbyrg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Unable to store static
On Thu, Oct 16, 2014 at 4:21 AM, Sachin Tiwariwrote: > > > > And added a below line in /settings.py, > > STATICFILES_DIRS = ( >os.path.join(PROJECT_PATH, "static"), >) I think you're repeating the 'static' subdirectory name. in the HTML try -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQZbLBzUorbg1X0o7E-yPE1%3Dfy1VRhreRL%2Bw733tp-J3g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: best aproach to pass an email from the url to a view?
On Fri, Oct 10, 2014 at 6:21 PM, dkwrote: > I been fighting to the get the email and passing it if you want to keep a value from one request to another, check the Session feature. In short, it works (almost) like a persistent dictionary private for each web user. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRqLOfmOvxagPFT0msRRR85MNiMis2KaWT_LgfR_i4OsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Config: DB or git?
On Mon, Sep 29, 2014 at 8:15 AM, Alejandro Varas G.wrote: >> But where does configuration belong? > > "To the environment" this is the currently fashionable answer, but I haven't seen any justification for it. Unfortunately, the 12factors manifesto tells the how, but very little of the why. In my experience, environment variables are clumsy, fragile and a pain to work with. I guess a more balanced option would be to store somewhere else, probably the database (although i'm not too opposed to VCS) with the host-variable parts (or everything, who cares about a couple KB extra storage?) as a set indexed by hostname, which is read from the environment. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS6LJXMwha5CO5MBm4NvUr8OUOOnTxX3dkSXwBNNjL%3DaQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What is *the* django 1.7 IDE which is opensource & multiplattform
On Wed, Sep 24, 2014 at 4:58 PM, John Schmittwrote: > I put my projects in virtualenvs which are in my VMs. It's not like one VM > can only host one project. > > Is that what you mean? not exactly. if you're using virtualenv, you can directly run the project in your workstation, no need to create any VM for development. save that for the staging step. of course, that's easy almost exclusively for Python projects, in other languages, (but several are getting virtualenv-like features) you might want to isolate and not pollute too much your workstation. in that case, using jails (lxc, docker, even chroot!) makes it easier to 'directly' edit without ssh or 'networked' filesystems. in the worst case (when even the smallest test requires some hardware i don't have), it's easy to add an rsync step to my test script. So i edit locally (with all my version control tools) and for each test all changes are propagated in less time that it takes to restart the process. i guess that what i'm trying to say is that a good editing environment [1] is the most important part of the setup, and it's unreasonable to compromise it just because i don't want the whole messy project requirements in my shiny workstation. [1] i like Kate, which does have remote access to files via ssh without even sshfs, thanks to KDE. but it still adds a split-second lag when i hit save, so i always edit locally, even if i test remotely. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoToPSPrbb_CXK-CiN%3D270y0yyVbx748_FAw2%2B%2BMcsxHCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What is *the* django 1.7 IDE which is opensource & multiplattform
On Wed, Sep 24, 2014 at 4:30 PM, John Schmittwrote: > When I'm creating a dummy project to test my apache configuration and/or my > management commands, or trying to assemble a complicated query, I do it > "live" on the VM on which I created the playground project. why bother with VMs when we have virtualenv? -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQuCNCKwex0F9ZbnU%3DSiYVAsz%3DwsRR2ZH4juX_a_i3Q-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Javascript requests after user login
On Tue, Sep 9, 2014 at 4:29 PM, Sarfraz Nawazwrote: > The problem is that I keep getting forbidden 403. Having looked around it > seems that it is because this request does not include the sessionid cookie > which is an http only cookie. have you checked the response content? more likely is that you're missing the csrf token [1]. (happens to me at least twice for each ajax-enable webapp i write) [1] https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS9FOOCW_rbA0KqBEtnKzCt%2BLNDqTRAWSkX_ZsPP-ekwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Concern about FastCGI deprecation
On Tue, Sep 2, 2014 at 2:15 PM, Shawn Hwrote: > Please provide a lifeline to those of us who love Django but have to use > IIS. Thanks. FastCGI isn't a Django concern, as it is a WSGI-only framework (like most Python frameworks). flup used to be a reasonable FastCGI WSGI container, but it's no longer supported, so it's unreasonable to ask the Django foundation to support it. the question is: what options are there to run WSGI under IIS? my first guess would be any HTTP-WSGI container (gunicorn?) and set IIS as a proxy. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRCjxjT2VqP%2BK7%3D-mu2Lj4LgZ_HYkiU4CTepZK17pQtLA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Custom management commands provided as only .pyc files?
On Wed, Aug 13, 2014 at 3:59 AM, Russell Keith-Mageewrote: > As I see it, you have four options: there's also option #2.5: * distribute .pyc files as required, but include a call to uncompyle2 (or any alternative .pyc to .py decoder) at setup time, so Django finds the .py files as usual. it not only follows the letter of the requirement ("thou shalt not give your .py files unto others"), but highlights how inappropriate it is. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQrXybRDCLr05F-DsZ-wBrUzq2Zz6YnW6omUDegunJcmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: What is the difference between running manage.py and ./manage.py?
On Sun, Aug 3, 2014 at 9:03 PM, Malik Rumiwrote: > Is this a Linux thing? on it's about the PATH variable. it's usually considered less safe to include '.' (the current directory) in PATH. Of course, that doesn't stop MS to put it right in the head of the default PATH value. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTdg8b_YQtnnrxjYF7sjp1zy8n%2BEt53Bz8qawcXouKoiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: django beginner
On Mon, Jul 7, 2014 at 8:17 AM, ngangsia akumbowrote: > But i have just created a separate app call photo, but when i run syncdb > nothing happens have you added it to INSTALLED_APPS in settings.py? -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQvmC4HThLfO9ZkGZLZuDKB1vVcnEVewiQ64KdrYhZjJw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Advanced SQL Question
On Thu, Jun 19, 2014 at 4:49 PM, G Zwrote: > how do I deal with concatenated foreign keys to form a primary key how do i > even register that in the models.py? i guess you mean composite keys. if so, then no; the Django ORM doesn't support composite primary keys. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ-xWC7%2B6xBt5ojFFRPMas6GYEB6O_G3WLm9%3DHZ%3D6N_Nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: Django Python roop
On Wed, Jun 11, 2014 at 8:12 AM, moqianc...@gmail.comwrote: > write right code, write clean code, It's a basic rule for our develope > work. for that you have to learn what the code means. "while x !=[]:" will always be an endless loop. the "[]" doesn't do what you think. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoR%2B4Ho8EBOJXs1eyn0NrrJGhfBa%2Bke7RSMT4Q4dut_LOw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: execute a code at a particular date and time (aperidic task) in django
On Tue, Jun 10, 2014 at 6:43 AM, Rini Michaelwrote: > Thanks for your reply,i have been looking into celery as well,but i found > that celery is used for periodic task and i am looking to execute aperiodic > task.please correct me if i am wrong check the T.apply_async(eta=) option [1] [1]: http://docs.celeryproject.org/en/latest/userguide/calling.html#id3 -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTVAe9HPXaotJUNL%3DNgFVH5_yEqaLJNbbWhgfhMCTDjhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: problem with django, nginx and gunicorn
On Thu, May 1, 2014 at 9:06 AM, 'ReneMarxis' via Django userswrote: > I started reading a little bit related to GIL. I think this is the root of > my problem. I'm using xhtml2pdf to generate some large pdf's (up to 200 > pages). no, the problem isn't the GIL. no matter the framework, language or architecture, if you take more than a few seconds to generate an HTTP response, users are going to complain. the appropriate approach for anything that takes more time is to dispatch to other process. that's why there are so many queue managers, they make it easier to allocate a task to be performed by other process. the high level process should be something like this: - user click on some "do it" button or link. it generates an HTTP request to do some work - the web app (a Django View in this case) gets the request, picks any necessary parameter and initiates a task. the task manager responds immediately with some ID. - the web app immediately generates a response for the user with some message like "process initiated, please wait" probably shows the ID, or maybe a link to the "is it ready" with this ID as a parameter. - meanwhile, the task/queue manager delivers the task parameters to a worker process. - if the user (or some Javascript) clicks the "is it ready" link, another Django view gets the task ID, checks the status and if it's not ready, shows the "please wait" message. - eventually, the task is finished, and the result (or some URL to a produced file) is stored in the task, under the same ID - when the "is it ready" view is hit again with this ID, it sees the task has finished, so it redirects to the "result" URL. about the task/queue manager, there are several available, from a simple register in a "tasks" table and a cron task to check any records there in the "unfinished" status (called a Ghetto queue), to the full-featured Celery. most of them allow you to define the tasks as simple Python functions with a @task decorator, and simply calling it results in the queuing of the arguments. something like this (semi-pseudocode): tasks.py from queue import task from models import MyModelA, MyModelB @task def dolotsofwork(userid, modelaid, someotherarg): user = User.objects.get(pk=userid) modA = MyModelA.get(pk=modelaid) .. do much more heavy processes return "result-%d.pdf" % resultId -- views.py from tasks import dolotsofwork def starttask(request, arg): user = request.user modela = get_object_or_404(MyModelA, pk=arg) taskid = dolotsofwork(user.id, modela.id, ..) return rendertemplate('pleasewait.html', {'taskid': taskid}) def isitready(request, taskid) status = queue.taskstatus(taskid) if status.isready(): return redirect(resulturl, taskid) return rendertemplate('pleasewait.html', {'taskid': taskid}) def resulturl(request, taskid): resultfilename = queue.taskresult(taskid) return rendertemplate('processready.html', {'resultfilename': resultfilename}) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTn0ZotVdzn5d%3DaxwCTZmTs8Fraki05yY2aev3b0eQM3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Relationships exposed over RESTful interface
On Fri, Apr 11, 2014 at 8:31 AM, Conrad Rowlandswrote: > As you can see the queryset is loading all from the database What I > would prefer to be able to do is to share the first queryset from the > ManufacturerModelViewSet (which should have all of the correct fields) with > the ManufacturerViewSet. I'm guessing this could be achieved by overriding > get_queryset in my ManufacturerViewSet though I don't know what to do from > there? first, you shouldn't use ManufacturerModel.objects.all(). in your get_queryset(), it should call the superclass' defintion and add the select_related() to it: def get_queryset(self): return super(ManufacturerModelViewSet, self).get_queryset().select_related() but in this case i guess the result is the same. It's just more flexible this way. It also helps to factorize it away in a mixin class as I suggested initially. the queryset returned by this method isn't used as-is; it's first passed to the filter_queryset() method. second, if you're talking only about one specific URI that is handled by ManufacturerModelViewSet, then it doesn't matter what you have or not in other viewset (ManufacturerViewSet); you could even delete it and it should still work the same. to see if it's possible to avoid the second query, first you have to know which part of the view requests it. a big help on this is the DjangoDebugTollbar. it works perfectly with the RestFramework API browser. Of course, if you're using the browser, remember that it can do extra queries to build the user-friendly HTML. those extra queries don't pass through your viewset methods, so it's unlikely they would respect the filters. to see what queries you do in production mode, set the logging config to report all queries to console or logfiles. (https://docs.djangoproject.com/en/1.6/topics/logging/#django-db-backends). or make the DB server itself log all queries. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRVcgGrAYUfvqPRoY0B_7i18c6WgZRBru%3DGw7bBqT_Ysg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Remind the users when their accounts are expiring
On Fri, Apr 11, 2014 at 6:39 AM, pije76wrote: > How to remind the users via email when their accounts are expiring based on > the time schedule (such as: 2 weeks away from deactivation & the day before > the deactivation itself). I wouldn't bother with searching for an app. just write a custom command (https://docs.djangoproject.com/en/1.6/howto/custom-management-commands/) that queries all accounts with some apropriate conditions. for example: (expiration date <= today+2weeks) and (last email date <= today - X days) and write the email for each one (https://docs.djangoproject.com/en/1.6/topics/email/). then have cron execute that command once a day. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQYgsCeK7RcipZZj6%2B5MB04gsUaNqMeXMzv6%2BFa5DLY4A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Relationships exposed over RESTful interface
On Fri, Apr 11, 2014 at 3:51 AM, Conrad Rowlandswrote: > I would still be keen to know if there is any know method that would allow > me to load this data using only the 1 queries bringing in all of the related > fields in the original query. what's the first query about? probably it's part of the authorization process, so it might not be appropriate to reduce to just one query. in any case, the exact number of queries is irrelevant. the important thing is to keep it constant for any data size. for example, a slightly complex task could easily need 10 queries but the final throughput you get from the system would be almost the same if it's 10 queries or just 1, as long as it's not (n+1) as you had before. of course, you still have to be sure the indexes are optimal to keep each query nice and tight! -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQ7niYrRkDSY7PwdyqKoc172R4X24h%3DYAodT4SaQBcXGA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Relationships exposed over RESTful interface
On Thu, Apr 10, 2014 at 8:29 AM, Conrad Rowlandswrote: > Why is this and how can I stop this behaviour but still bring back the > Manufacturer Details. I expected instead the first query to load all of the > data. override the get_collection() method in your View (or ViewSet) to add a select_related(). for example, something like this (untested!): add this mixin to your View and optionally set the related_fields: class SelectRelatedMixin(object): related_fields = () def get_queryset(self): return super(SelectRelatedMixin, self).get_queryset().select_related(*self.related_fields) class ManufacturerModelViewSet(SelectRelatedMixin, viewsets.ModelViewSet): related_fields = ('manufacturer',) . the rest of your viewset -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTLYS9DwdfTtGBBOVHgSyRyU1tqnXs6qui5aYUUzEcKCw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Making functions callable
On Wed, Mar 26, 2014 at 5:53 PM, Anthonywrote: > I've yet to test it but I read a few people stating to use lambdas > variables/properties. Is it definitely the case that it will only evaluate > once? from the python docs (2.7): Default parameter values are evaluated when the function definition is executed. This means that the expression is evaluated once, when the function is defined, and that the same “pre-computed” value is used for each call. This is especially important to understand when a default parameter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQimq3%2B6b4mpT3qdWvP%3DfgDM9STEcLLdN3mx1MHTRaGkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Class that extends a model that is not a model
On Wed, Mar 5, 2014 at 10:52 AM, Tom Evanswrote: > Your derived classes are models, and they should be models. What they > shouldn't be is have different tables for each model type, there > should be one table that all instances are stored in to, as the data > for each Calculation instance, regardless of type, is the same. > > This is a common idiom in ORMs, and is called Single Table Inheritance: > > http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html > > Django doesn't support STI, but that doesn't really matter, you can > get the same behaviour by using composition rather than inheritance, > something like this: that sounds very similar to django's proxy models: https://docs.djangoproject.com/en/1.6/topics/db/models/#proxy-models but I agree that this kind of problems are typically better solved byt composition rather than inheritance. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSi0ETcKpTfRMNe1ziAXWhV%3DTgvdoeVzgW6jDaXxxN9EA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: big legacy database with complex many to many relationships
On Mon, Feb 24, 2014 at 2:54 PM, Sells, Fredwrote: > I have to integrate to a large read only legacy mssql database . while certainly it's possible to configure this as a second database and use the ORM, I've found that it's more work than usually needed. especially if you already have defined SQL patterns, or worse, stored procedures. porting those to ORM means debugging them again... but there's nothing preventing you from using any Python way to access that data. particularly if you're going to treat it as read-only. just write some utility functions that use ODBC or any other interface to pull your data and use that in your Django views, or even in your models. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoS1WBGDN80v5J%2BCh%2BXCx_g1SD2obvjG51AqO_YJA0mM7w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: looking for recommendations for django app for managing tv commercial post production
On Thu, Feb 20, 2014 at 1:38 PM, Adam Tealewrote: > We are 10 people working in tv commercial post production. We work with > reasonable amount of data from video, photos, graphics, audio. > I'm hoping to find something that gets us off to a good start regarding user > management and authentication, hopefully time tracking, client management > and asset management. not Django, but TACTIC (http://www.southpawtech.com/) is an Open source DAM with roots on video postproduction and workflow. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQrHVYLO55ug%3D%3DUOuP%3D7Cn_MhY0Y5UgvyX%2BkfMwymqYEA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: what is the Fastest django application server?
the fastest server is the one that doesn't do anything useful. as soon as you've got an application to handle requests, the magnitude of any difference between all these (and others) drops below random noise levels. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT1R1jU9GWFXwLP%2BXqH_Yw6EwwCdfVSUi_X7wG%3DjhYtpA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: FieldError, But Only In Production
On Thu, Feb 13, 2014 at 7:09 PM, Rich Joneswrote: > We're good now. No idea what the hell was happening, but this works now. > Humbling to realize how little I know about the ORM internals. are you using virtualenv? it's possible that mod_wsgi was executing in a different environment than the test server. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSSrY5pe0gt1pXP9LjEQmkfh7_SncHYR8rvfBA7yenwnQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: FieldError, But Only In Production
On Thu, Feb 13, 2014 at 5:49 PM, Rich Joneswrote: > Since this seems to happening at a pretty deep level, would it be uncouth to > kick this over do django-dev? django-dev is not 'django support, level 2'. it's about the development of the Django framework. if you have a concrete proposal, or a full bug report, then by all means take it there. but for usage questions, this is the right place. also, most (if not all) members of django-dev also participate actively here. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT60MAsGB%2BRpZwpcEKFuRy40bu0Qr0MD%3DPsQnnC929Q7A%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Dyanmically changing Django Storage?
On Mon, Jan 27, 2014 at 3:07 PM, zwebwrote: > During run time, based on file size and type, I want to use a different > storage backend. How to do it? write a storage backend proxy that picks which 'real' backend to use for each file. note that during upload, you have to start storing before knowing the full size of the file. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRxkzGb1z3uLt%2B6WzFoKpgq6F05c7xdH9cqqLMhfHof8w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: failure of auto increment in inndb (mysql)
On Mon, Jan 27, 2014 at 2:13 PM, Tom Lockhartwrote: > MySQL started as a non-ACID query server (not a full relational database in > the accepted sense) and these kinds of issues likely stem from that history. > Folks getting started with databases and django may want to consider using > Postgres for their foundation. it's true that MySQL started as a very limited project and grew from there, meaning that there are still several shortcomings when compared with more complete and robust implementations, like Postgresql. but this specific issue, isn't because of that history. in fact, the old MyISAM storage engine handles it differently: autoincrement fields are monotonically incrementing. (unless the storage gets corrupted). it's the InnoDB implementation the one that didn't bother to handle full monotonicity, considering the uniqueness and incrementing conditions enough. AFAIR, the SQL standard doesn't require full monotonicity... does it even define autoincrement fields? if there's no hard standard, i don't think it could be considered a bug. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQNwnC-3Ka3X1SS6%2Bk-%3DfMaxmj0DEKgV3QmMf4vkQQOyw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Fast and Easy way to check if an instance of an Model exists in the Database
On Thu, Jan 16, 2014 at 11:50 AM, Johannes Schneiderwrote: > The point is, I have to distinguish between an instance which is created, > but its save method is not yet called. And an instance coming from the > database via a manager. AFAIK, if it has a 'pk' property, it has been saved. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSOhujBWX2XJuD6FH7CgQFxZXZRJ7%2BD2Y7imP5uF3HmnQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: need django.cache advice
On Thu, Jan 9, 2014 at 4:43 PM, Sells, Fredwrote: > > Fred: I was unclear. The initial join is 1 x 1000 x 20 x 100 ... which > gets reduced to about 1000 records. A few records are changed every second. are the 'interesting' 1000 out-records always the same, or changing slowly? is it easy to test if any specifc in-record alters the result or not? if yes on both, then you might invert the calculation, from a 'pull' method (the current) to a 'push', where you keep the result precalculated and on each modification you test if it's worthwhile to redo it. this assumes: A.- the process is expensive to do every time for every client (that's the problem) B.- it's cheap to verify if the new data alters the result (my initial questions) C.- the queries are frequent enough that few precalcs would be unseen. (i guess so given the number of clients and rate of queries) if condition C doesn't hold, but B does, then another thing to try: - on each query, first check if the answer is already precalculated. if it is, just get that - if it's not, do the job and store in the cache - on each input modification, check if it alters the result. if so, just delete the cache. finally, if condition B doesn't hold, just store the result in a cache entry that expires in a minute. that means that the process would occur at most once a minute and the clients could get results that are at most a minute old. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQf0PDDAMTjCzUp92jHk%2BS34CDcMt9iJS4uRTCJf%2BLQKw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: migrating DailyStockSelect.com to django
On Mon, Dec 23, 2013 at 6:02 AM, d sswrote: > best would be to provide me directly with the recommended tools to perform > the following: honestly, no matter how experienced you are in Python, if you're new to Django, the best and fastest way to get you running is to do the tutorial. not only it does introduce you to Django as a library, but also to the way that the different parts of it fit together. and in the end, it establishes some common language that makes it *much* easier to ask for extra help here. cheers, -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQvwwAExJeRKJqcbSQ1w-UT_mO7Ko%2BC8mfQvHMJ5nY0wQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Trying to run jobs in the background using multiprocessing
On Thu, Nov 28, 2013 at 2:42 AM, Pau Creixellwrote: > I guess if there isn't another simpler way, I'll have to dig into Celery. there _are_ simpler alternatives to Celery: - worker threads: similar to your proposal, but with very well-thought process control. pros: no extra process. cons: very hard to get it even half right, very easy to kill your web workers with the lightest load. probably unsupported by hostings. - ghetto queues: a db table + a cron process. pros: simple, easy to debug. cons: has a hard ceiling, if the queue grows over some (hard to estimate) limit, it grinds to a halt. - uWSGI spool: extra uWSGI containers that work on a queue of tasks. pros: easy to use, you get the process management by uWSGI, no extra tools. cons: limited semantics, might not be supported by hosts. - simple brokers: for example pub/sub or other structures in Redis. pros: easier to use and understand than celery, might be lighter on memory. cons: no standarization, needs a broker process (at least if you're not already running Redis), might not be supported by hostings. as you can see, in most cases the only reasonable answers are Celery or ghetto queues. the last ones are an easy way out, and if done well can serve to a surprising load level; but if you hit gold, it will fall down. this scheme was a big part of the Twitter growing problems. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRZJEiEMc2cJP2OzXFAouViNDNY%3DwdqkwOVoWbr2tvsKw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Problem with raw query and using in
On Sat, Nov 16, 2013 at 7:40 AM, Thorsten Sanderswrote: > realms=[1] > data = AuctionData.objects.filter(itemid__exact=itemid,realm__in=realms) > data2 = AuctionData.objects.raw('SELECT * FROM auctiondata_auctiondata WHERE > itemid_id=%s AND realm_id in %s ',[itemid,realms]) not sure if it's related. but most SQL adaptors use a tuple for the IN(...) parameters, not a list. check http://initd.org/psycopg/docs/usage.html#tuples-adaptation -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTSsD%2B8S0rdvOnHVCBxxF6UzRCK9jzscTW4Ff677Yt_dw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Streaming images with HttpResponse?
On Fri, Nov 15, 2013 at 12:08 PM, Jorge Cardoso Leitãowrote: > I believe that is not possible with Django views. Views are made for > request-response, i.e. the client sends a request, the view returns a > response, and that's it, end of connection. i think the WSGI standard does support it, by setting a generator instead of a string value as the response content. the generator is a function that yield()s more content each time, so the HTTP response becomes a stream of data. but i think you're right that Django doesn't support it. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQaCYa%2BwGRKtZcjvY%3DyE-0%2Bz0THUMj%2BZOftZeykCREuNQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Fixture extraction
On Thu, Nov 14, 2013 at 3:12 AM, Anton Pirkerwrote: > The optimal solution would be that I can give a number of auth_users to a > script, and it will extract all data neccessary to have a complete set of > data for the given users. > > A plus would be, if the email addresses of the users would be anonymized and > the password would be set to some default password. check the serializers doc. it's not hard to get a queryset and export as a fixture. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSQzj1OxAbjE%3DhPbkQBj71MsTrYUdK4ZTXEYLVRFBhXYw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Stroring images in the database
On Tue, Nov 12, 2013 at 8:57 AM, m1chaelwrote: > People have always recommended to me that storing images directly in a > database is a bad idea. it IS a bad idea, but that doesn't mean it shouldn't be possible. there are several Storage subclasses that do that, and it's not hard to do another one. The original question seems to use one of these, but it's not clear exactly which one. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoT-uEyeZgvrwre6RbNKHwL1nfV-1THGS5biC40_R_A-Jw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complex query reduction
On Fri, Nov 8, 2013 at 1:44 AM, Robin St.Clairwrote: > The last time I checked the use of IN, all the records from the database in > the query were brought back to the workstation, rather than being processed > on the backend and only the results returned to the workstation. Django ORM's __in operator tries to use SQL facilities, but depending on the type of object passed, it could read the list of options and pass it explicitly, or it could merge two SQL commands. always check the type of SQL commands generated! (debug toolbar is your friend) i haven't seen it doing a post-retrieve check in python, thought. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRLfeLi%3DWVu5f%3DcyCXRH0x5mr1fbDiV0OzW%2Bn-fpk6uHw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Seeking reviewers for a "Guide to Idiomatic Django Deployment"
On Tue, Nov 5, 2013 at 7:34 PM, George Londonwrote: > > I think it would be really helpful for new-comers to have a clear, > opinionated guide to "commonly accepted (i.e. idiomatic)" deployment best > practices. Or at least I know it would have really helped me. wish you the best luck, hopefully it will be a usefull resource for us all. as for my 2bits of advice: remember that there's not "single one" best and recommended deployment strategy. AFAIK, there are at least three options that just _have_ to be considered: - nginx + uWSGI (pros: most flexible process handling, can be the fastest of all) - Apache + mod_wsgi (pros: integration in Apache ecosystem, makes process handling almost transparent, maybe the only good choice for windows servers) - nginx + gunicorn (pros: mostly python, good docs, can be used without nginx for development) honestly, covering these three is a "make or break" for me. that is, I would never recommend anybody (no matter how newbie) a deployment guide that doesn't cover at least those. (of course, a real newbie shouldn't have to get into deployment issues until needed. the development setup is more than enough to learn the platform) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoTRp5WUC2hYP7szyCrT3-8jCME0RUuVjcc5qZZZW%2BaU6Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complex query reduction
On Fri, Nov 1, 2013 at 12:45 PM, Daniele Procidawrote: > In practice I use some tweaks (such as values_list) to speed this up, and > caching, but the fundamental pattern is the same. It's slow, because there > are 30 thousand BibliographicRecords. the total number of records shouldn't matter. more important is the number of selected records at some points in the query. i'd guess the number of chosen entities (those that _are_ descendant of the first one), and the number of chosen researches (those that _are_ members of those entities) should be the most significant quantities. the point is that most DB optimizers are somewhat shy to shuffle conditions around IN operators. but it might be easier to work on a small (a few tens of values?) IN condition than on a very long JOIN chain. > > I'm trying to rearrange the construction of the query in different ways to > find a speed improvement. I don't think that either prefetch_related or > select_related will help here, but perhaps there are some other tools that > would. have you tried eliminating the second IN relationship? something like entities = entity.get_descendants() items = BibliographicRecord.objects.filter(authored__researcher__person__member_of__entity__in=entities).distinct() that should turn most of the query in a long sequence of "INNER JOIN", giving the optimizer an easier job, avoiding the IN operation on research records. if the query chooses too many researches, this could be a big part of the slowness. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoSVg3K44wRUnOTrinqXZbVKm1ZZLHxFPB8LdgrzBtxViA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Defining new project as a service at nignx
On Mon, Oct 14, 2013 at 12:17 PM, Muhammed TÜFEKYAPANwrote: > I use digitalocean as a server. I upload my django project files on my > server and start to setup. Made postgresql settings etc but I can't define > my new project as a new service on nginx. How can I define my new projest as > a service and make possible to start it as "service blabla start". > > When I type "service --statıs-all" I can't see my new project now. i think you're mixing two things and missing a third. 1: AFAIK, nginx doesn't have "services", just serves requests via some methods, either static files, internal plugins or backend servers. 2: on most linux distros, the 'service' command manages startup scripts; with start/stop commands to run daemons. 3: nginx doesn't run python applications, you have to run them in an app server. for Django, (and most python frameworks), the best option is a wsgi server. One that runs really well with nginx is uWSGI. another option is to run gunicorn as an HTTP backend server behind nginx. so, which is your deployment strategy? (https://docs.djangoproject.com/en/1.6/howto/deployment/) -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoQhk7BtAz8aDQZv79cea76A3MJM-tpWVToPhr-3jAPKdw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.