Re: Multiple databases

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

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

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

Multiple databases

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

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

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,

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

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

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

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

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

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"

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

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,

Re: possible bug - CharField accepts string as max_length

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

Re: possible bug - CharField accepts string as max_length

Yes, it is. user=> \d+table django_foo; Table "public.grd_device" Column | Type | Modifiers | Storage | Stats target | Description ++---+--+--+- id | integer

Re: possible bug - CharField accepts string as max_length

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

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

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

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

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 >