Re: Multiple uwsgi apps in one project

Thanks. Could you explain last point about 3 different sites? As I said I'd like to have separate middlewares and urls. Currently I have two Django projects defined, they share app paths and most of settings (middlewares are redefined and urls are separate). Marcin W dniu piątek, 26 maja 201

Re: Multiple uwsgi apps in one project

I think that my reqs are pretty straightforward. I'd like to setup project environment with 3 different apps: 1. main app (public) 2. admin app (vpn) 3. local network app for api talking with other services in the datacenter The whole thing is about preserving same project environm

Multiple uwsgi apps in one project

Hi. I'd like to serve more uwsgi apps for the same project. These apps must have just separate urls and must be served on spearate domains. I'd like to have separate appservers. The rest, i.e. project's environment, should stay same. How to achieve that? I know I can create a new django pro

Re: Alternative to celery

RQ is simple, stable and reliable. Redis is also a persistent storage, but you should read about this and use the best solution for your case: https://redis.io/topics/persistence You may also consider deploying a fault-tolerant Redis cluster (min. 3 nodes AFAIR) RQ has different architecture

Re: Angular 2 + Django + Postgresql

>From my personal experience: - make frontend (angular) almost 100% separate from backend (django) - if you want to build truly restful service, avoid DRF (more precisely -- avoid whole "magical" model views, which implements CRUD antipattern) - focus on hypermedia (i.e. use Hydra, or

Re: field cannot be specified for model form as it is a non-editable field

Thank you for all replies. @James Your proposal about design change is generally OK, but while doing the upgrade I definitely DO NOT want to change the implementation. It is just too risky. @Tim Sorry for hostile sounding, but I'm just tired of such drastic changes. For a x-years long pro

field cannot be specified for model form as it is a non-editable field

Hi. After upgrading to 1.11 I'm getting this error: FieldError: created_at cannot be specified for model form as it is a non-editable field. First of all, the model contains created_at field declared as DateTimeField(auto_now_add=True). Probably that's why it is non-editable. But I cannot se

Re: Automatic content types removal

Thanks, Tim. I'll take a look at this. > From the Django 1.11 release notes: > >- The prompt for stale content type deletion no longer occurs after >running the migrate command. Use the new remove_stale_contenttypes > >

Django forks / clones / wrappers

Hi Does anyone know a web framework, non full-stack / microframework, but partially compatible with Django (in terms of the programming interface)? Django have too many design flaws for big projects, so I'd like to move into something less coupled. Any bridges / wrappers for Flask maybe? The co

Automatic content types removal

Hi. Why Django automatically removes content types? Due to lack of flexibility in auth system I was forced to create custom content type for custom perms. Now I've realized that my custom content type is missing. I am not sure, of course, but I think that Django removed my CT silently. I know

OneToOne mappings

Hi. The problem is: A 1:1 B B.a = OneToOne(A) and there is a vA - an unmanaged model of A's view A and B are linked together. vA view is not linked with B, of course. When I try to declare OneToOne within vA, Django expects vA.b_id field which is missing (that's ok). When I try to declar

Re: Migrations

On Friday, March 10, 2017 at 9:18:42 PM UTC+1, Matthew Pava wrote: > > Does anyone else get a migraine when working migrations? > Yes*. Long time ago. Stayed with Liquibase wrapped with Liquimigrate. Builtin migrations are pretty unrielable, because they're strongly dependent on your applicati

Re: group by 3 fields

On Wednesday, March 1, 2017 at 2:09:06 PM UTC+1, larry@gmail.com wrote: > > > I had thought of using a view, but that would have been a lot of > overhead on such a large table. I also considered adding a column and > running a one time script to update the existing rows, and modifying > th

Re: group by 3 fields

> > As is so often the case, the requirements changed. Now what I had to > do, if I was doing it in SQL would have been: > > (CASE > WHEN TRIM(IFNULL(roiname, '')) IN ('', 'None') THEN CONCAT_WS('.', > CONVERT(roi_type_id, CHAR), roi_id) > WHEN CONCAT_WS('.', CONVERT(roi_type_id, CHAR), ro

Re: Flattening model relationships (in APIs)

Wanna read something interesting? Look at http://t-code.pl/blog/2016/02/rest-misconceptions-0/ You will realize how many "antipatterns" are propagated in turorials on our World Wide Web, and where they're already implemented. On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrot

Re: Flattening model relationships (in APIs)

On Monday, February 27, 2017 at 3:38:34 PM UTC+1, Xavier Ordoquy wrote: > > > The more strict RESTfull way would be to use the several entry points and > use hyperlinks on them (though it would add some extra requests). > > This is just about representation. Nobody forces you to do such things.

Re: Flattening model relationships (in APIs)

On Monday, February 27, 2017 at 3:30:11 PM UTC+1, Ankush Thakur wrote: > > I guess this is the library in question: > https://github.com/marcinn/restosaur (took some effort to find it!). > Thanks, if I decide to stick with the API-first approach, I'll use it. > Either way, I've bookmarked it f

Re: Flattening model relationships (in APIs)

I was limited by DRF long days ago and I realized that it is not following REST architecutre. It does good job in automation in exposing models over http, but everything else is way complicated. But there were no problem mix both tools in one project. DRF was for "80%" of work and my lib for the

Re: Flattening model relationships (in APIs)

I'm not sure you want to read my answer, really... I've finally stopped using DRF and wrote own library which is focused on resources, linking and representations. I think you can do some customization in DRF, probably you ca declare custom serializer class, but this is a hard way, IMO. I like

Re: group by 3 fields

On Monday, February 27, 2017 at 3:52:38 AM UTC+1, larry@gmail.com wrote: > > [SQL] That is a language I > have worked in for over 20 years, and when I see a querying need that > is how I think, and then I see how can I do that with the ORM. > So I shouldn't give advices for you. We have s

Re: Flattening model relationships (in APIs)

On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote: > > If the relationship chain was even deeper, there would be even more > nesting, which I feel isn't great for API consumers. What is the best > practice here to put state and country at the same level as the city? > Jus

Re: group by 3 fields

On Sunday, February 26, 2017 at 12:55:17 PM UTC+1, Daniel Roseman wrote: > > > You should explain what you want to achieve. Grouping is pointless on its > own. In any case, when working with an ORM like Django's it is generally > not helpful to think in terms of SQL. > -- > DR. > Also forget

Re: Migrations with multiple databases

On Tuesday, October 25, 2016 at 5:05:46 PM UTC+2, andrea crotti wrote: > > We have a couple of databases with a tiny number of tables, but > django-migrations has still go through all the migrations anyway. > So even if the SQL itself is nothing it still takes a massive amount of > time and mem

Re: Disabling migrations when running tests

On Sunday, July 17, 2016 at 3:08:49 AM UTC+2, Tim Graham wrote: > > You can use MIGRATION_MODULES for this: > https://docs.djangoproject.com/en/1.9/ref/settings/#migration-modules > > Also, there's a ticket to simplify disabling of migrations during tests > further: https://code.djangoproject.c

Re: Disabling migrations when running tests

On Sunday, July 17, 2016 at 12:20:30 AM UTC+2, James Schneider wrote: > > > > > I don't need automatically created test databases nor migrations > applied. Can I disable this? > > > > I don't know of a way to do so. You're probably better off using a > separate test suite than relying on manage

Re: Disabling migrations when running tests

On Saturday, July 16, 2016 at 11:57:18 PM UTC+2, Ryan Castner wrote: > > Could you explain what you mean by running tests? > Yes. I'm talking about "manage.py test". The docs says: "New in Django 1.8 [...] If the database does not exist, it will first be created. *Any migrations will also be

Disabling migrations when running tests

Hi all. Is possible to disable migrations execution when running tests? Thanks, Marcin -- 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...

Re: Django 1.9 Apps aren't loaded yet

On Monday, April 25, 2016 at 11:44:20 PM UTC+2, marcin@gmail.com wrote: > Just wondering about possibility to do some kind of late initialization. I've found Dectate library as a example of deferring configuration phase. I'm not talking about using it

Re: Django 1.9 Apps aren't loaded yet

Hi James, good to hear you. It is very good that app initialization is done within a special stage. I remember many problems related to imports and I'm happy that they will not occur anymore. I understand what is done and what for. Just wondering about possibility to do some kind of late init

Re: Django 1.9 Apps aren't loaded yet

The initialization process of models seems to be good step in cleaning many problems, but I don't understant why I can't import models. The usage of the model should raise exception when it is not loaded/initialized, but not importing a model class! This requirement breaks packages encapsulation

Re: Turn off migrations completely in Django 1.7

On Wednesday, August 26, 2015 at 1:08:51 PM UTC+2, grzegorz.stalmierski wrote: > > > With current architecture around migrations Django > is database owner, not one of the database services. > > Application layer is chaning over time and its lifetime is a way shorter than database and data. Mi

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

On Friday, February 27, 2015 at 11:22:13 PM UTC+1, Gergely Polonkai wrote: > > Hello, > > another solution may be to patch your models in the migration module or > class > The best solution is not to use Django built-in migrations. Of course you can create them very quickly (via automatic "ma

Re: GROUP BY without using aggregate function

On Thursday, March 3, 2016 at 2:28:58 PM UTC+1, Michal Petrucha wrote: > > > Merely based on your vague description, it seems to me that this is > one of the cases where you might be better off writing your SQL query > manually. > > Narrowing results by `filter()` is very handy, in contrast to

Re: GROUP BY without using aggregate function

On Wednesday, March 2, 2016 at 6:11:32 PM UTC+1, Dan Tagg wrote: > > if your aren't counting or averaging then why are you grouping? > > > To fast find distinct values within big dataset - some queries on some engines may be faster when using grouping. It was known technique years ago and I'm s

GROUP BY without using aggregate function

Hello, I would like to query database with Django ORM and add GROUP BY clause without including unnecessary counting, avg, etc. I can force/hack queryset by settting qs.query.group_by=['my_column'], but this is unclean and risky. Is possible something like: MyModel.objects.filter(...).group_by

How to disable atomic() in tests

Hi, I want to disable atomic() in tests (Django 1.8 and newer). I would like to "noop" it and implement alternate BEGIN-ROLLBACK sequence for every test. Anyone did this? It comes from bad design of Django tests, where database is created, cleaned, dropped, fixtrue-loaded in every test, which

Re: [Django 1.8.6] How to dump sql from models

Mike, thanks. I have no migration directories, so assuming that it would not help. Tim, also thanks. I've checked that django-dev discussion, but no updates here. I don't want to discuss again and again about kicking out useful tools. It looks like reimplementing old commands is the only way.

[Django 1.8.6] How to dump sql from models

Hi! After upgrade from 1.5 to 1.8.6 I'm trying to dump sql from models. I'm not using django migrations, and my db_router does not allow for migrations. Every "sql*" management command gives me nothing (empty output), where I'm expecting generated SQL. 1. How can I dump tables and indices

Re: I'm a Flask/Android developer in need of advice. Is Django a good fit for my next project: a no-transaction marketplace website/mobile app?

On Sunday, October 25, 2015 at 5:43:50 PM UTC+1, Kitti Wateesatogkij wrote: > > > I'm interested in django if there's a package that fits my requirements so > I don't have to do it all manually in Flask. If possible please recommend > such packages for me. > > Django will give you more tools O

Re: can I write Django a client consuming RESTfull api from elsewhere

> > > On Wednesday 04 November 2015 10:43 PM, Avraham Serour wrote: > So I have to use a client connection object such as Python request > So I want to keep it as global, so that all views can access it from a > single location, instead of creating a client request instance for every > view on

Re: Django 1.7 migrations: Adding one field to User`s model

On Wednesday, August 26, 2015 at 8:23:01 PM UTC+2, Carl Meyer wrote: > > > I think that for this use case "Custom user" will not work. I was wrong. > > I must forget about "Custom user". ;) > > Yes. I think the most important Django limitation here is how difficult > it is to switch from built

Re: Django 1.7 migrations: Adding one field to User`s model

Thanks, Hugo. My project already contains migrations. I've added migration with RunSQL. Monkey patch is detected for "django.contrib.auth" app, and Django tries to add migration in python egg (Django). I'm avoiding calling "makemigrations" without args (or "auth" as an argument). This is a D

Re: Turn off migrations completely in Django 1.7

On Tuesday, April 28, 2015 at 7:20:17 AM UTC+2, Mike Dewhirst wrote: > > Anyway, I suspect disabling migration - even if a > "master-switch" could be built - is undesirable if one is using any of > the django tables. > > > I'm not sure we're talking about the same. Some of us don't need built

Django 1.7 migrations: Adding one field to User`s model

Hi, I would like to add one field to User. I've created new model based on original Django`s user: class User(AbstractUser): is_verified = models.BooleanField(default=False) class Meta: db_table = 'auth_user' Now I'm trying to make migrations, but Django tries to create `auth

Re: Django 1.8, migrations and database views

Oh my s**t. Django generates operation but does not execute it when migrating. What a mess... Solved by Django itself... On Tuesday, August 4, 2015 at 5:21:07 PM UTC+2, marcin@gmail.com wrote: > > Hi, > > Who knows how to disable auto-making migrations for models mapped to > database vie

Django 1.8, migrations and database views

Hi, Who knows how to disable auto-making migrations for models mapped to database views? I've set managed=False but it does nothing. Django adds CreateModel operation to migration file, but it shouldn't do that. Can anyone help? Thanks. BR, Marcin -- You received this message because you ar

Re: Django Migrations - Relation Already Exists

I'm not a newbie. Just avoid Django (South) migrations and syncdb. My advice - generate complete SQL for your project (based on migrations or sql and sqlindexes commands), move changes to reliable tool (i.e. Liquibase) as an initial migration, tune changesets if needed, and forget about builtin

Re: Migrations During Development

It depends about your workflow - if migrations were applied only on your machine, revert them and modify. South migrations (and Django migrations, which were based on South) may be problematic in speific cases, i.e. during merging or when executed unintentionally from uncleaned *.pyc files, but

Re: Turn off migrations completely in Django 1.7

So what about that? I'm also interested in disabling migrations. I need to upgrade Django in big project (from 1.4 to newer version) because of lack of support for 1.4, but migrations included in v1.7 will complicate this process. I want to disable everything related to migrations. We're using

Re: Model form with optional fields issue

On Tuesday, December 23, 2014 3:49:07 AM UTC+1, James Schneider wrote: > > Have you looked at the Django REST Framework module? > Yes, I have. They wrote own serializers and fields for validation, and they don't use builtin forms. Personally I don't like DRF API, because it is too heavy and not

Re: Model form with optional fields issue

> > > > What do you think - is this expected? > > Yes, this is expected. Django's form system is designed for use with > HTML forms, which do not provide partial data: unchanged field values > are sent too, so this problem does not occur. > I thought that Web framework can validate RESTful(-l

Model form with optional fields issue

Hello! I have model form defined with all optional fields (required=False). I want use this form to update only provided fields leaving others unchanged. But Django replaces optional fields to empty values and removes data from models. A short example: class MyForm(forms.ModelForm): class