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

[marcin . j . nowak]

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-in User to custom User. That's a real 
> problem, and it should be fixed (but at the moment I'm not sure how to 
> fix it). 
>
>
Maybe this is related to migrations. I must check someday source code of 
"custom user" implementation, then maybe I could give you some thoughts...

Better support for monkeypatching is not very interesting. 
>
>
Right, Carl. And this wasn't my intention. You give me a hint in other 
thread and it was helpful, but MP has some side effects (with migrations, 
again).
PS. I don't like monkey patching, personally.

Cheers,
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...@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/d6d7bc37-e898-4c1a-8d4c-96ad9a84ace9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Carl Meyer]

On 08/26/2015 12:18 PM, Marcin Nowak wrote:
> 
> On 26 August 2015 at 20:09, Hugo Osvaldo Barrera  > wrote:
> 
> Oh, so the field you're adding in monkey patching contrib.auth.User?
> IMHO, the design problem isn't django, but rather monkey-patching
> models itself. Maybe you'd be better of using a custom user model.
> 
> 
> I've tried to use custom user model, but Django forces me to change all
> FK`s. This is not possible for now.
> 
> I need to add just one column / field to existing User model. Nothing
> more, nothing less.
> 
> AFAIK I should create profile for user and put this column into profile
> model, but there are two disadvantages: 
> 
>   * the profile is not necessary now and will contain just one column
> (well, three when incl. PK and FK to user)
>   * performance issues (joining table)
> 
> 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-in User to custom User. That's a real
problem, and it should be fixed (but at the moment I'm not sure how to
fix it).

Better support for monkeypatching is not very interesting.

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


signature.asc
Description: OpenPGP digital signature

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

[Marcin Nowak]

On 26 August 2015 at 20:09, Hugo Osvaldo Barrera  wrote:

> Oh, so the field you're adding in monkey patching contrib.auth.User?
> IMHO, the design problem isn't django, but rather monkey-patching models
> itself. Maybe you'd be better of using a custom user model.
>

I've tried to use custom user model, but Django forces me to change all
FK`s. This is not possible for now.

I need to add just one column / field to existing User model. Nothing more,
nothing less.

AFAIK I should create profile for user and put this column into profile
model, but there are two disadvantages:

   - the profile is not necessary now and will contain just one column
   (well, three when incl. PK and FK to user)
   - performance issues (joining table)

I think that for this use case "Custom user" will not work. I was wrong. I
must forget about "Custom user". ;)

BR,
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...@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/CAB2m7CzRVk%3DG-8JzHECbEH%3DZueP3BibBxZkV-vurBp3ND1aaZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

['Hugo Osvaldo Barrera' via Django users]

On Wed, Aug 26, 2015, at 15:02, marcin.j.no...@gmail.com wrote:
> 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 Django migrations design problem... :(
>
> BR, Marcin

Oh, so the field you're adding in monkey patching contrib.auth.User?
IMHO, the design problem isn't django, but rather monkey-patching models
itself. Maybe you'd be better of using a custom user model.

--
Hugo Osvaldo Barrera
 

-- 
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/1440612540.2788907.366827321.6EA613D4%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

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

[marcin . j . nowak]

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 Django migrations design problem... :(
 
BR,
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...@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/dd2950e1-c26e-4818-a86f-4d1654f11924%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 26 August 2015 at 16:50, Carl Meyer  wrote:

> At this point the discussion belongs on the django-developers list, to
> enumerate the real-world use cases and sort out the pros and cons of the
> various possibilities. Getting a change into Django is rarely
> impossible, but it does require committing some time and energy to
> discussion and evaluation of the options.
>


I can specifiy some use cases.

1. Using Django as a part of bigger stack, where databases are maintained
by external tool and no schema nor data modifications should be applied
automatically.

2. Avoiding limitations/forcings of builitin migration system and Django
ORM.

By using external database migration tool developers have flexibility and
possibility to "do things right" (from db perspective).
Models are used as an read/write interface with a subset of fields.
Anf it was working good up to 1.7, and may work good with migrations turned
off.

3. https://code.djangoproject.com/ticket/23159

Wontfix, because does not fit design concepts of *migrations*. Without
migrations everything is OK and works as expeced. In that case migrations
are not feature but a real limitation.


And last, but not real use case (just design concept):

4. Improper migrations design

Django migrations are apps-related, same as South was. This is a not the
best possible design.
There is, for example, possibility to generate migrations within python
eggs (even in Django itself).
Migrations should be project-wide and splitted by database.
Developer should have possibility to change database schema as he need
without forcing limitations of model-based migration system.
Not every table is mapped to model.

Kind Regards,
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...@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/CAB2m7CzKoSezwPMgQk3MZe9R-1JcmF6wA6n756tS5UBXOPR12g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Grzegorz Stalmierski]

2015-08-26 16:15 GMT+02:00 Carl Meyer :

> You quoted me out of context.


​I'm sorry. It was unintentional. ​

--
​Regards,
​Greg Stalmierski.​

-- 
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/CADzPLA%3D8Lt6QnOzkso8-bkc8d2%3DHU9oAMQ9JB9TaKtZcQF%2BarA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Carl Meyer]

On 08/26/2015 08:15 AM, Carl Meyer wrote:
> I agree, and I already suggested a new feature (`managed=False` at the
> AppConfig level) for which I think a solid patch would most likely be
> accepted. This new feature would be capable of handling the "don't
> migrate anything" case as well as the wide variety of "migrate these
> apps but not those" cases. 

Another option might be to leverage the existing `MIGRATION_MODULES`
setting, allowing a value of `None` to mean "ignore migrations for this
app, I will manage its schema myself outside of Django."

At this point the discussion belongs on the django-developers list, to
enumerate the real-world use cases and sort out the pros and cons of the
various possibilities. Getting a change into Django is rarely
impossible, but it does require committing some time and energy to
discussion and evaluation of the options.

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


signature.asc
Description: OpenPGP digital signature

Re: Turn off migrations completely in Django 1.7

[Carl Meyer]

Hi Grzegorz,

> On Aug 26, 2015, at 2:25 AM, Grzegorz Stalmierski 
>  wrote:
> 
> W dniu 25.08.2015 o 19:04, Marcin Nowak pisze:
>> 
>> I would like to provide solid patch as a pull request, but I'm afraid that 
>> it will be rejected due to some kind of spirit, politics or something else. 
>> 
>> BR,
>> Marcin
> Marcin, please - consider sharing your patch on GitHub (or similar)
> with a documentation, because:
> It is not possible to build a framework where _everything_ is easy. We
> aim for "Simple things should be easy, advanced things should be possible."
> 
> Carl
> this is not so advanced thing, and it looks almost 
> impossible to solve in Django. 
> With current architecture around migrations Django 
> is database owner, not one of the database services.
> 

I agree, and I already suggested a new feature (`managed=False` at the 
AppConfig level) for which I think a solid patch would most likely be accepted. 
This new feature would be capable of handling the "don't migrate anything" case 
as well as the wide variety of "migrate these apps but not those" cases. 

You quoted me out of context. My quote was in reply to Marcin complaining that 
even _that_ feature would still be too much work to use. I wasn't claiming the 
status quo is sufficient for this. 

FWIW I don't think a single new setting to switch off migrations for all apps 
is 100% out of the question, if it turns out there are a number of people who 
would use it. I'd like to hear a little more specifics from such people about 
their use case. I don't think a global flag is as generally useful as the above 
feature, and it would need to come with some pretty strong warnings in the 
docs. For instance, Django may modify models in contrib apps and ship 
migrations for them in future versions, and of course third party apps will 
commonly do the same. So anyone using such a global flag is accepting 
responsibility for watching out for such schema changes themselves, or their 
project may break when they upgrade Django or another app. 

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/5770D7A2-FDEC-41C2-BA60-674CE7E974DA%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: ForeignKey Fields null=True does not imply blank=True

[Mark Caglienzi]

On 26 Aug  2:59, khoobks wrote:
> Hi All,

Hello!

> To me, this seems like an unnecessary trap for users of the Django 
> Framework. However there may be a design decision here and I'd love to be 
> educated on why there would be a situation where it makes sense for 
> null=True and blank=False.

Well, maybe it's useful if you want to be able to programmatically
(a.k.a. in the backend, or with a management command, maybe even called
by a cronjob) create some objects with that FK set to NULL (probably
because in your case you cannot possibly know how to set it), but you
want to force the user to specify a value when updating them (so in that
moment the blank=True will enforce this behaviour).

> Regards
> Ben

Regards,
Mark

-- 
. ''`.  | GPG Public Key  : 0xCD542422 - Download it from http://is.gd/fOa7Vm
: :'  : | GPG Fingerprint : 0823 A40D F31B 67A8 5621 AD32 E293 A2EB CD54 2422
`. `'`  | Powered by Debian GNU/Linux, http://www.debian.org
  `-| Try not. Do, or do not. There is no try. - Master Yoda, TESB.

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

Re: ForeignKey Fields null=True does not imply blank=True

[khoobks]

It just occurred to me where I went wrong. 

I have a line that makes the form field non-required which means the form 
won't flag the validation error. 

Thanks Florian

On Wednesday, 26 August 2015 20:18:48 UTC+8, khoobks wrote:
>
> That makes sense however I would have expected the ModelForm to give an 
> error indicating that the foreign key is blank (when it should not be) 
> instead of adding it to the exclusion list meaning that it never gets 
> updated when you call save.
>
>
>
> On Wednesday, 26 August 2015 19:43:16 UTC+8, Florian Schweikert wrote:
>>
>> On 26/08/15 11:59, khoobks wrote: 
>> > I just discovered some interesting behaviour in Django 1.8.4 and was 
>> > wondering if this was an unexpected side effect or specifically 
>> designed 
>> > behaviour. 
>>
>> That behaviour is intended and documented[0]. 
>>
>> blank and null working on completely different levels. 
>> blank is only for validation in the django code. 
>> null affects the database field. 
>>
>> It's useful if you like to force the user to input something in a field, 
>> but at the same time you have to initialise a model with null at some 
>> other place in your code. 
>> e.g you are importing email addresses, but don't have names in your 
>> current data. You can now easily force the user to set his/her name when 
>> changing settings, without overwriting fields in a form. 
>>
>> regards, 
>> Florian 
>>
>> [0] https://docs.djangoproject.com/en/1.8/ref/models/fields/#null 
>>
>>

-- 
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/101de680-22d4-4250-bee6-7695be943358%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ForeignKey Fields null=True does not imply blank=True

[khoobks]

That makes sense however I would have expected the ModelForm to give an 
error indicating that the foreign key is blank (when it should not be) 
instead of adding it to the exclusion list meaning that it never gets 
updated when you call save.



On Wednesday, 26 August 2015 19:43:16 UTC+8, Florian Schweikert wrote:
>
> On 26/08/15 11:59, khoobks wrote: 
> > I just discovered some interesting behaviour in Django 1.8.4 and was 
> > wondering if this was an unexpected side effect or specifically designed 
> > behaviour. 
>
> That behaviour is intended and documented[0]. 
>
> blank and null working on completely different levels. 
> blank is only for validation in the django code. 
> null affects the database field. 
>
> It's useful if you like to force the user to input something in a field, 
> but at the same time you have to initialise a model with null at some 
> other place in your code. 
> e.g you are importing email addresses, but don't have names in your 
> current data. You can now easily force the user to set his/her name when 
> changing settings, without overwriting fields in a form. 
>
> regards, 
> Florian 
>
> [0] https://docs.djangoproject.com/en/1.8/ref/models/fields/#null 
>
>

-- 
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/fda4148a-e5fb-482c-9c9d-e1f17a782ba3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ForeignKey Fields null=True does not imply blank=True

[Florian Schweikert]

On 26/08/15 11:59, khoobks wrote:
> I just discovered some interesting behaviour in Django 1.8.4 and was
> wondering if this was an unexpected side effect or specifically designed
> behaviour.

That behaviour is intended and documented[0].

blank and null working on completely different levels.
blank is only for validation in the django code.
null affects the database field.

It's useful if you like to force the user to input something in a field,
but at the same time you have to initialise a model with null at some
other place in your code.
e.g you are importing email addresses, but don't have names in your
current data. You can now easily force the user to set his/her name when
changing settings, without overwriting fields in a form.

regards,
Florian

[0] https://docs.djangoproject.com/en/1.8/ref/models/fields/#null

-- 
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/55DDA5FB.3080600%40ist-total.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Turn off migrations completely in Django 1.7

[Remco Gerlich]

On Tue, Aug 25, 2015 at 5:27 PM, Carl Meyer  wrote:

> To my knowledge, out of the many hundreds of
> thousands of Django users, you are the first and only one to request a
> way to turn off migrations entirely.
>

I think that's a little unfair, given that migrations are only in Django
since 1.7, which isn't even a year old yet. On older versions it was just a
matter of not using South. I think there are quite a lot of < 1.7 projects
that don't use South.

That said, another way not mentioned yet: database routers have an
allow_migrate method. Maybe use a two-database solution with a router, one
database for the Django-internal tables that want to be able to migrate,
and one for your company's data that always returns allow_migrate False?

Greetings,
Remco Gerlich

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

Re: Turn off migrations completely in Django 1.7

[Grzegorz Stalmierski]

W dniu 25.08.2015 o 19:04, Marcin Nowak pisze:


I would like to provide solid patch as a pull request, but I'm afraid 
that it will be rejected due to some kind of spirit, politics or 
something else.


BR,
Marcin

Marcin, please - consider sharing your patch on GitHub (or similar)
with a documentation, because:

   It is not possible to build a framework where_everything_  is easy. We
   aim for "Simple things should be easy, advanced things should be possible."

   Carl

this is not so advanced thing, and it looks almost
impossible to solve in Django.
With current architecture around migrations Django
is database owner, not one of the database services.

I'm almost certain this patch will gather new contributors.

--
Regards,
Greg

--
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/55DD77DE.4020508%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

ForeignKey Fields null=True does not imply blank=True

[khoobks]

Hi All,

I just discovered some interesting behaviour in Django 1.8.4 and was 
wondering if this was an unexpected side effect or specifically designed 
behaviour.


class UserProfile(models.Model):
# Notice that I do not say that blank=True
my_other_model = models.ForeignKey('my_app.OtherModel', null=True)


I would have expected that since it doesn't make sense for a ForeignKey to 
have a 'blank' value, by saying that null=True it would implicitly mean 
that blank=True.
However to my surprise this is not the case.

This came to my attention when using ModelForms. I found out that it is 
possible to assign the foreign key in the Form to a non null value, but it 
was not possible to reassign it back to the 'blank/null' value.

The reason is that in django/forms/models.py there is a function called 
'_get_validation_exclusions'. This function does a check on line 376

if not f.blank and not form_field.required and field_value in 
form_field.empty_values

which specifically looks at the 'blank' attribute of the model field. If 
this is False, then you will go into the if block and your field will be 
added to the exclusion list and therefore never saved.

To me, this seems like an unnecessary trap for users of the Django 
Framework. However there may be a design decision here and I'd love to be 
educated on why there would be a situation where it makes sense for 
null=True and blank=False.

Regards
Ben

-- 
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/9a3dda01-eab8-4b53-8c24-5cb05414c2a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Recursive model queries

[Shekar Tippur]

Hello,

I am trying to use https://github.com/heywbj/django-rest-framework-recursive

I need to be able to run query on a recursive model that gives the name of 
the parent and child

My model

class RecursiveModel(models.Model):
   stage_title = models.CharField(max_length=255, unique=True)
parent = models.ForeignKey('self', null=True)

I need to get the names of parent and child relationship
Equivalant query being:

select c.id, c.stage_title as child, p.stage_title as parent from 
recursivemodel c, recursivemodel p  where c.parent_id=p.id

How do I do that?

When I run it, I get:

Cannot assign "'stgabc'": 
"RecursiveModel_Deferred_created_data_parent_id_stage_title.parent" must be a 
"RecursiveModel" instance.


- Shekar

-- 
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/26e3b1e5-5ba9-4959-9a36-52cc35d33ca7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading scikit model in Django

[James Schneider]

> Thanks you James for your suggestion. I am going to look into the
memcached now.
>
> I was thinking that the ideal solution will be to load the model into a
global variable, then the request can use refer to this variable for the
model. I don't know if that possible.
>

Possible...yes. Good idea? Well, let's just say a cache is what you need in
this case. I'm hoping that your objects can be serialized or pickled, that
will make them much easier to store in the cache. This will also make it
easier to support concurrent users with different objects in the cache.

The tough part is going to be maintaining a consistent state for the object
in the cache if the user is making changes to it (updating the instance and
then updating the cache with the new object so that further request are
working with current data).

You may also want to consider handling changes via a batch job processor
such as Celery if the updates are lengthy (locking the object for updates,
retrieving the object, updating it, saving it to the DB or a file, and then
updating the cache with the new version). That way your users get an
instant response saying that their changes have been submitted and the
updated version should be available shortly. It really depends on your user
base and the timing of operations.

Start with implementing the cache, once that is working, look at a batch
processor like celery if the response is still less than desirable, since
there is a fair amount of setup required to get a batch processor online.

I've never worked with custom memcached entries, so I've reached the end of
my knowledge scope here.

-James

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