Re: Multiple databases

[Javier Guerra Giraldez]

On Mon, May 18, 2015 at 7:35 PM, Roger Dunn  wrote:
> 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: Cannot resolve keyword -> on reverse ForeignKey after upgrade to 1.8

[James Schneider]

My guess is a select_related('follow') call somewhere is causing the issue.
The behavior for select_related() changed in 1.8.

Can you post the entire trace back?

-James
On May 18, 2015 4:49 PM, "Galia Ladiray"  wrote:

> Hi,
> I wonder if anyone can help me, or just share the pain ...
>
> I have some code that goes like this (this is a very simplified version of
> my code):
> -
> class Follower(models.Model):
> follower = models.ForeignKey(MyUser, related_name='followed_by')
> followed = models.ForeignKey(MyUser, related_name='follow')
>
> Class MyUser(models.Model):
> some fields
>
> def get_followed(self, limit=16):
> return MyUser.objects.filter(follow__follower__id=self.pk)
> -
>
> This used to work fine, BUT after upgrade to django 1.8 I get an error
> message:
>
> Cannot resolve keyword 'follow' into field. Choices are: (some fields and 
> ...), follow
>
> (which is a bit frustrating error message)
>
> I tried to recreate this on a new project (so I can post real code!) but I
> cannot recreate the error, maybe something to do with the way tables were
> names before and are named now on the DB?
> I have a feeling it is something to do with the django 1.7 application
> loader (regarding naming) but it used to work fine in 1.7
>
> Any ideas will be highly appreciated
>
> Thanks
> Galia Ladiray-Weiss
>
> --
> 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/d58285fb-b7cd-40c7-9750-ee89b3bddc54%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2Be%2BciV%3DDeqZObti%2Bjwfm-yU6cgU0dAbNJfYVA7XQfKO6F0y1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Multiple databases

[Roger Dunn]

I'm spinning up a new project and nearly all of the data I need to store 
can be normalized. Along with this normalized data is one piece that is 
better suited to a nosql database. 

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. 

I'm thinking of doing a hybrid using the 2 technologies. There will be a 1 
for 1 relationship by rows. I know I could do either nosql or mysql, but 
for the exercise thinking of doing both. 

Any examples floating around for this?

-- 
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/272ad26a-0ed5-478e-8da6-2c35646b68a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cannot resolve keyword -> on reverse ForeignKey after upgrade to 1.8

[Galia Ladiray]

Hi,
I wonder if anyone can help me, or just share the pain ...

I have some code that goes like this (this is a very simplified version of 
my code):
-
class Follower(models.Model):
follower = models.ForeignKey(MyUser, related_name='followed_by')
followed = models.ForeignKey(MyUser, related_name='follow')

Class MyUser(models.Model):
    some fields

def get_followed(self, limit=16):
return MyUser.objects.filter(follow__follower__id=self.pk)
-

This used to work fine, BUT after upgrade to django 1.8 I get an error 
message:

Cannot resolve keyword 'follow' into field. Choices are: (some fields and ...), 
follow

(which is a bit frustrating error message)

I tried to recreate this on a new project (so I can post real code!) but I 
cannot recreate the error, maybe something to do with the way tables were 
names before and are named now on the DB?
I have a feeling it is something to do with the django 1.7 application 
loader (regarding naming) but it used to work fine in 1.7

Any ideas will be highly appreciated

Thanks
Galia Ladiray-Weiss  

-- 
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/d58285fb-b7cd-40c7-9750-ee89b3bddc54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a one field to user model: trying not to create custom one)

[James Schneider]

The point of using a OneToOne relation to create a 'profile' is that the
profile is meant to contain information that is only accessed on an
individual basis (such as displaying a single users' address, etc.), and
generally not involved on bulk queries as you describe.

If your __str__() method in your primary user model accesses an attribute
via a foreign key lookup (ie OneToOne), then you'll get the behavior you
are describing. You want the data that you'll need all or most of the time
in the primary model to avoid that situation. In this case, I would suggest
you look at the attribute you're referencing and move it directly into the
primary user model.

I'm a little worried about what you mean by 'monkey patching'. Did you just
override the __str__() methods on your primary model?

-James
On May 18, 2015 3:58 PM, "Ilya Kazakevich"  wrote:

> Hello,
>
> I want to add just a one field to my model, and this field participates in
> user representation ( I use monkeypatch to change __str__).
>
> Django manual tells me to create profile with one-to-one relation in this
> case. Well, it may work. But if I have  with 250 users, I face 250
> "SELECT" queries to my db (N+1). I need to tell "UserManager" somehow to
> use "select_related". But how can I do that with out of new ugly
> monkeypatching?
> Does there is an official (recommended) way to do that? If no, how  can I
> use one-to-one user profile if I have "list of users" webpage with out of
> N+1? How to add one field to user model not extending it?
>
> I am really unhappy with idea of using custom user model.
> Thanks.
>
>
>  --
> 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/5bdd87b6-9cc6-4490-8b85-d25ecfe8ed16%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2Be%2BciVa3Fqte4584jOfT99vQE4CfprbyrBnwEL%2BwuxapGRcew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a one field to user model: trying not to create custom one)

[Carl Meyer]

Hello Ilya,

On 05/18/2015 04:58 PM, Ilya Kazakevich wrote:
> I want to add just a one field to my model, and this field participates
> in user representation ( I use monkeypatch to change __str__).
> 
> Django manual tells me to create profile with one-to-one relation in
> this case. Well, it may work. But if I have  with 250 users, I
> face 250 "SELECT" queries to my db (N+1). I need to tell "UserManager"
> somehow to use "select_related". But how can I do that with out of new
> ugly monkeypatching?
> Does there is an official (recommended) way to do that? If no, how  can
> I use one-to-one user profile if I have "list of users" webpage with out
> of N+1? How to add one field to user model not extending it?

I am not aware of a good solution to this problem other than manually
adding the .select_related() to your query on the list-of-users page.

> I am really unhappy with idea of using custom user model.

Why?

If it's because this is an existing project and the prospect of
migrating your existing data to a custom user model is daunting, I
totally understand that. It's doable, but hard.

If this is a new project, I think that there is no good reason to avoid
a custom user model. Every new project should always use a custom user
model, even if to begin with it just inherits from AbstractUser and
doesn't change or add anything. This way in the future you have control
over your user model and can modify it as needed without monkeypatching.

Carl

-- 
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/555A72A0.2070105%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Adding a one field to user model: trying not to create custom one)

[Ilya Kazakevich]

Hello,

I want to add just a one field to my model, and this field participates in 
user representation ( I use monkeypatch to change __str__).

Django manual tells me to create profile with one-to-one relation in this 
case. Well, it may work. But if I have  with 250 users, I face 250 
"SELECT" queries to my db (N+1). I need to tell "UserManager" somehow to 
use "select_related". But how can I do that with out of new ugly 
monkeypatching?
Does there is an official (recommended) way to do that? If no, how  can I 
use one-to-one user profile if I have "list of users" webpage with out of 
N+1? How to add one field to user model not extending it?

I am really unhappy with idea of using custom user model.
Thanks.


-- 
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/5bdd87b6-9cc6-4490-8b85-d25ecfe8ed16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to change type of field in model, when database is already populated ?

[Larry Martell]

On Sat, May 16, 2015 at 9:26 AM, mangu rajpurohit
 wrote:
> Hi,
>
> I am new to Django. I am working on an application ,where the types of table
> fields in database are not known before hand. So, say for eg. In student
> table, I am assigning CharField to marks field, ie
>
> class Student(models.Model):
>  marks = model.CharField(max_length = 3)
>
> and after Student table in database is populated, can I change the type of
> marks to IntegerField as shown below :-
>
> class Student(models.Model):
>  marks = model.IntegerField()
>
>
> Is it possible ? If not feasible, then what are the alternatives ways/design
> strategies or what should be done in such cases ? If feasible, then what are
> its side-effects ?

Why can't you just alter the table:

alter table student modify marks int;

-- 
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/CACwCsY7C0dKNRfMcCv1C%2Bvwq89R0huu0krU7jp6uoTR%3D3jLNQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible bug - CharField accepts string as max_length

[James Schneider]

I'd post a bug report. Based on the behavior you've outlined (haven't
looked at the Django source), there may have been some oversight on the
duck typing that python performs. It sounds like the migration package is
taking advantage of duck typing (since 16 == int('16')), but the validation
functions are making comparisons on the assumption that 16 is an int, not a
str.

If you really want to double check before filing, forward your question
over to the dev mailing list.

This may be a good opportunity to provide a patch if you haven't done so
before.

-James
On May 18, 2015 1:13 AM, "Santiago L"  wrote:

> Yes, it is.
>
> user=> \d+table django_foo;
>   Table "public.grd_device"
>  Column |  Type  | Modifiers | Storage  | Stats target |
> Description
>
> ++---+--+--+-
>  id | integer| not null default
> nextval('django_foo_id_seq'::regclass) | plain   |  |
>  bar| character varying(16)  | not null  | extended |  |
>
>
>
>
>
> El lunes, 18 de mayo de 2015, 9:37:31 (UTC+2), aRkadeFR escribió:
>>
>>  Hey,
>>
>> And is the CharField is really 16 char max_length in DB if
>> you specifiy a string '16'?
>>
>> On 05/15/2015 10:53 AM, Santiago L wrote:
>>
>> Hi,
>>
>>  I think that I have found a bug on the system check: it accepts a
>> string as value for CharField.max_length argument.
>>
>>  It happens only if the string can be converted to int (e.g.
>> max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo').
>>
>>   from django.db import models
>>
>> class Foo(models.Model):
>> bar = models.CharField(max_length='16')
>>
>>
>> # following code raises an Exception
>> obj = Foo(bar='lorem ipsum')
>> obj.clean_fields()
>>
>>
>>  Traceback:
>>   >>> obj = Foo(bar='lorem ipsum')
>> >>> obj.clean_fields()
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py",
>> line 1167, in clean_fields
>> setattr(self, f.attname, f.clean(raw_value, self))
>>   File
>> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py",
>> line 589, in clean
>> self.run_validators(value)
>>   File
>> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py",
>> line 541, in run_validators
>> v(value)
>>   File
>> "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line
>> 280, in __call__
>> if self.compare(cleaned, self.limit_value):
>>   File
>> "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line
>> 319, in 
>> compare = lambda self, a, b: a > b
>> TypeError: unorderable types: int() > str()
>>
>> Best regards,
>>
>>  Santiago
>>  --
>> 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...@googlegroups.com.
>> To post to this group, send email to django...@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/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> aRkadeFR
>>
>>   --
> 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/cf3c4d3e-e1be-4ed8-88e9-8bd2851676e6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2Be%2BciU-uYMRNdrQJcWasFuqdnWQGteKKy6-02RD5Ah-epGCrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible bug - CharField accepts string as max_length

[Santiago L]

Yes, it is.

user=> \d+table django_foo;
  Table "public.grd_device"
 Column |  Type  | Modifiers | Storage  | Stats target | 
Description 
++---+--+--+-
 id | integer| not null default 
nextval('django_foo_id_seq'::regclass) | plain   |  |
 bar| character varying(16)  | not null  | extended |  | 





El lunes, 18 de mayo de 2015, 9:37:31 (UTC+2), aRkadeFR escribió:
>
>  Hey,
>
> And is the CharField is really 16 char max_length in DB if
> you specifiy a string '16'?
>
> On 05/15/2015 10:53 AM, Santiago L wrote:
>  
> Hi, 
>
>  I think that I have found a bug on the system check: it accepts a string 
> as value for CharField.max_length argument.
>
>  It happens only if the string can be converted to int (e.g. 
> max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo').
>
>   from django.db import models
>
> class Foo(models.Model):
> bar = models.CharField(max_length='16')
>
>
> # following code raises an Exception
> obj = Foo(bar='lorem ipsum')
> obj.clean_fields()
>  
>
>  Traceback:
>   >>> obj = Foo(bar='lorem ipsum')
> >>> obj.clean_fields()
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py", 
> line 1167, in clean_fields
> setattr(self, f.attname, f.clean(raw_value, self))
>   File 
> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
> line 589, in clean
> self.run_validators(value)
>   File 
> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
> line 541, in run_validators
> v(value)
>   File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
> line 280, in __call__
> if self.compare(cleaned, self.limit_value):
>   File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
> line 319, in 
> compare = lambda self, a, b: a > b
> TypeError: unorderable types: int() > str()
>  
> Best regards,
>
>  Santiago
>  -- 
> 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...@googlegroups.com .
> To post to this group, send email to django...@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/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> aRkadeFR
>
> 

-- 
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/cf3c4d3e-e1be-4ed8-88e9-8bd2851676e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: possible bug - CharField accepts string as max_length

[aRkadeFR]

Hey,

And is the CharField is really 16 char max_length in DB if
you specifiy a string '16'?

On 05/15/2015 10:53 AM, Santiago L wrote:

Hi,

I think that I have found a bug on the system check: it accepts a 
string as value for CharField.max_length argument.


It happens only if the string can be converted to int (e.g. 
max_length='16'). Otherwise shows fields.E121 error (e.g. 
max_length='foo').


|
fromdjango.db importmodels

classFoo(models.Model):
bar =models.CharField(max_length='16')


# following code raises an Exception
obj =Foo(bar='lorem ipsum')
obj.clean_fields()
|


Traceback:
|
>>> obj = Foo(bar='lorem ipsum')
>>> obj.clean_fields()
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/base.py", 
line 1167, in clean_fields

setattr(self, f.attname, f.clean(raw_value, self))
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
line 589, in clean

self.run_validators(value)
  File 
"/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", 
line 541, in run_validators

v(value)
  File 
"/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
line 280, in __call__

if self.compare(cleaned, self.limit_value):
  File 
"/usr/local/lib/python3.4/dist-packages/django/core/validators.py", 
line 319, in 

compare = lambda self, a, b: a > b
TypeError: unorderable types: int() > str()
|

Best regards,

Santiago
--
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/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
aRkadeFR

--
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/5559966E.5080608%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug in QuerySet API when chaining filter() and update() methods?

[aRkadeFR]

Hey!

Maybe you should open a ticket :)

Have a good one

On 05/14/2015 08:13 PM, Alejandro Treviño wrote:

Hello everyone, first-time poster here!

I ran into an interesting scenario earlier today that I thought was 
worth sharing:


Given this update statement using the django ORM:

>>> pks = MyModel.objects.all().values_list('pk', flat=True)
>>> pks
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, '...(remaining elements 
truncated)...']

>>> MyModel.objects.filter(pk__in=pks).update(foo_field=True)

When pks is a "reasonably small" size, the django ORM generates this 
(valid) SQL statement:


UPDATE `djangoapp_mymodel` SET `foo_field` = 1 WHERE 
`djangoapp_mymodel`.`id` IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)


However, when pks is very large (300k records on my data set), it 
generates this instead:


UPDATE `djangoapp_mymodel` SET `foo_field` = 1 WHERE 
`djangoapp_mymodel`.`id` IN (SELECT U0.`id` FROM `djangoapp_mymodel` U0)


Which is not allowed in MySQL:

django.db.utils.OperationalError: (1093, "You can't specify target 
table 'djangoapp_mymodel' for update in FROM clause")



I'm wondering if this classifies as a bug, or if this is just a known 
limitation?  My workaround is to just do the updates in smaller 
batches.  An update on 100k records still generated valid SQL for me, 
but I haven't done enough testing to figure out what cut-off point is.


*Environment:*
Python 3.4.2
Django 1.8.1

mysql  Ver 14.14 Distrib 5.5.43, for osx10.8 (i386) using readline 5.1


Thanks!

Alex

--
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/10d0d83b-733a-47d2-b5d1-6f9c904269a6%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
aRkadeFR

--
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/55599603.6070902%40arkade.info.
For more options, visit https://groups.google.com/d/optout.

Re: Django model inheritance: create sub-instance of existing instance (downcast)?

[guettli]

Thank you Simon. I did not know save_base(raw=True) before.

Am Mittwoch, 13. Mai 2015 16:43:36 UTC+2 schrieb Simon Charette:
>
> Hi Guettli,
>
> This isn't part of the public API but you could rely on how Django loads 
> fixture internally 
> 
> .
>
> parent = Restaurant.objects.get(name__iexact="Bob's Place").parent
> bar = Bar(parent=parent, happy_hour=True)
> bar.save_base(raw=True)
>
> Keep in mind that this could break with any new version of Django.
>
> Simon
>
> Le mercredi 13 mai 2015 05:25:50 UTC-4, guettli a écrit :
>>
>> Thank you for this link. The InheritanceManager is good to know about. 
>> But it does not help creating the child_instance from a base instance. At 
>> least the docs don't tell about it. Or I was blind.
>>
>> Am Mittwoch, 13. Mai 2015 05:41:44 UTC+2 schrieb somecallitblues:
>>>
>>> Have you had a look at 
>>> http://django-model-utils.readthedocs.org/en/latest/managers.html#inheritancemanager?
>>>  
>>> I'm not sure if it will help but it's kind of related to what you've posted.
>>>
>>> On 12 May 2015 at 23:10, guettli  wrote:
>>>
 Hi,

 this ticket is seven years old

 https://code.djangoproject.com/ticket/7623

 {{{

 As it exists now, multi-table inheritance does not allow for the 
 creation of a child model instance that inherits from an existing parent 
 model instance. For example:
  
 Parent Class-
  
 class Place(models.Model):
 name = models.CharField(max_length=50)
 address = models.TextField(max_length=150)

 Child Classes-
  
 class Restaurant(Place):
 place = models.OneToOneField(Place, parent_link=True)
 cuisine = models.CharField(max_length=75)
 rating = models.IntegerField()

 class Bar(Place):
 parent = models.OneToOneField(Place, parent_link=True)
 happy_hour = models.BooleanField()
 beers_on_tap = models.ManyToManyField("Beers", null=True, blank=True)

 Sample Use-case-
  
 When the system is first deployed, a restaurant instance is created. 
 Later, the restaurant adds a bar to increase revenue, and we now want to 
 create a Bar model instance for the parent Place for the restaurant. I 
 would propose the following interface for doing so:
  
 parentPlace = Restaurant.objects.get(name__iexact="Bob's Place").parent
 barInstance = Bar(parent=parentPlace, happy_hour=True)

 However, if you attempt to create an instance in this manner now, you 
 receive a DatabaseIntegrityError, saying that a Place object with that id 
 already exists.

 }}}

 How to get this solved?

 There are work arounds:


 http://stackoverflow.com/questions/4064808/django-model-inheritance-create-sub-instance-of-existing-instance-downcast

 {{{
 extended_user = ExtendedUser(user_ptr_id=auth_user.pk)
 extended_user.__dict__.update(auth_user.__dict__)
 extended_user.save()
 }}}

 Or is there a better solution in current django versions?






  

 -- 
 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...@googlegroups.com.
 To post to this group, send email to django...@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/d4273754-670e-4697-b0b4-9626c42a5aaf%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>

-- 
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/4a1b1bce-6f5d-4a04-ba40-66b27cb9caef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.