>From django 1.7 it is done by the migration
Change your Models class
run makemigrations, it will recognise the change and create a migration file
run migrate command, which will alter the database
On Saturday, May 16, 2015 at 3:26:32 PM UTC+2, mangu rajpurohit wrote:
>
> Hi,
>
> I am new to Dja
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 js
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
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
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_
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
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
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" qu
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.M
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
functio
Yes, it is.
user=> \d+table django_foo;
Table "public.grd_device"
Column | Type | Modifiers | Storage | Stats target |
Description
++---+--+--+-
id | integer
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
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
13 matches
Mail list logo