Re: Requesting eyeballs on a change to SQLite schema editor

2015-02-12 Thread Alex Hill
Standalone PR now at https://github.com/django/django/pull/4122.

Alex

On Thursday, February 12, 2015 at 12:09:39 PM UTC+8, Alex Hill wrote:
>
> Hi all, doing a bit of yak shaving here.
>
> I'm currently refactoring Django's lazy operations [0], and ran into a bit 
> of a snag which led me to make some changes to SQLite's schema editor. All 
> the tests pass, but I thought I should bring this up here to get a few more 
> eyeballs on my changes since it's a pretty critical bit of Django 
> infrastructure.
>
> Here's the relevant change: 
> https://github.com/AlexHill/django/commit/d27869e3dcb03eccf7c3aa09d911b5206bda9d0a
>
> *Explanation:*
> SQLite requires creating a new table for many schema alterations.
>
> At present the process is:
>
>1. define a dummy model with the updated definition and table name 
>"app_model__new"
>2. create that model's table
>3. copy the data from "app_model" into "app_model__new"
>4. delete the "app_model" table
>5. rename "app_model__new" to "app_model"
>
> Consider a model with a foreign key to self called "parent". In master, 
> that field on the dummy model actually points to the original model, with 
> the correct table name. After the refactor, the dummy model is internally 
> consistent, i.e. its parent field points at itself, with its temporary 
> table name. After you create the new table "app_model__new" and rename it 
> to "app_model", its definition is left with a dangling reference to 
> "app_model__new".
>
> An equivalent way to do this is:
>
>1. define a dummy model with the updated definition and the existing 
>table name "app_model"
>2. rename "app_model" to "app_model__old"
>3. create the dummy model's table
>4. copy the data from "app_model__old" to "app_model"
>5. delete the "app_model__old" table
>
> This avoids ever having a model with a db_table set to the temporary table 
> name. As well as fixing my problem, this seems a little more 
> straightforward – there's a bit of awkward search-and-replace happening 
> with the "__new" table name in the schema editor which we avoid this way.
>
> Cheers,
> Alex
>
> [0] https://code.djangoproject.com/ticket/24215
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9d2b55ba-9119-46ca-9718-505d3c437658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


1.8 bug fix sprinting this weekend

2015-02-12 Thread Tim Graham
If you would like to contribute to the timely release of 1.8 and if you 
have some free time over the next couple days, please consider working on 
something from this list (whether it is writing a patch, reviewing an 
existing patch, or triaging an issue):

https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime

These are my top priorities until the beta release (scheduled for Monday), 
but if you have other small bug fixes, they will also happily be considered.

I will be available in #django-dev most of tomorrow (~12:00 UTC - 0:00 UTC) 
and on Saturday (~12:00 UTC - 19:00 UTC) if you need guidance (and there 
are many other helpful people around in case I am not). I invite other 
members of the team to participate and post their availability to cover 
other timezones.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f4f80156-041f-4e82-a36c-4a648cb845ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: status of 1.8 release blockers

2015-02-12 Thread Markus Holtermann
Hey Tim,

Thanks for the update. Could you check if #24282 is fixed by my PR as well and 
assign it to me in case it is. The error message looks familiar to the one I 
commented on the PR. Thanks.

/Markus

On February 13, 2015 2:33:38 AM GMT+01:00, Tim Graham  
wrote:
>Status of release blockers:
>
>#24320  Unable to
>serialize 
>UUIDField when running dumpdata with JSON format 
>
>Status: I wrote a failing test and will try to write a patch tomorrow
>if no 
>one else takes a look first.
>
>#24289  Is usage of 
>many_to_one and one_to_many terms confusing for relation flags? 
>
>Status: We are waiting for feedback/confirmation from Anssi and Russ
>about 
>the direction to take here.
>
>#24225  KeyError when 
>migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3) 
>
>#24264  foreign key
>constraint 
>error migrating integer pk to CharField 
>
>Status: Markus has a patch which addresses both issues. It's in good
>shape 
>and should be ready for commit soon.
>
>#24282  Cannot Modify
>Foreign 
>Keys Within Data Migrations
>
>Status: This is awaiting a test case to reproduce the issue (I'll 
>investigate tomorrow if no one else does).
>
>Here is the filter for 1.8 release blockers as well as issues tagged
>1.8 
>beta or 1.8 and thus are on my radar to make a decision on in the next 
>couple days:
>https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime
>
>On Wednesday, February 4, 2015 at 9:45:33 AM UTC-5, Tim Graham wrote:
>>
>> Reminder that the 1.8 beta release is scheduled for twelve days from
>now: 
>> Monday, February 16. 
>>
>> Please check this filter for remaining blockers for beta:
>>
>>
>>
>https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=assigned=new=~1.8-beta=id=summary=status=owner=type=component=changetime=1=changetime
>>
>> I'll follow up next week to ensure we have owners for any issues that
>
>> remain after the weekend.
>>
>> On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>>>
>>> I think master is stabilizing and the number of unsolved regressions
>
>>> should be ~0 by tomorrow. I'd like to release the alpha around 2100
>UTC 
>>> tomorrow +/- ~4 hours depending on how things go with the remaining
>issues. 
>>> Let me know if there is anything you think needs to be in the alpha
>that 
>>> wouldn't meet this deadline.
>>>
>>> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn
>wrote:

 Congratulations! Looks like you've steadily moved it through.

 Tino

 On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham 
>wrote:

> We did it -- all features are in or out for alpha. Please consider
>
> master frozen for new features until we cut the stable/1.8.x
>branch later 
> this week. Feel free to commit code cleanups and/or bug fixes
>until then.
>
>
> On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>>
>> Here is the fifth update with several days to go until alpha. I 
>> believe we are on track for a feature freeze at the end of day on
>Monday. 
>> Let's see how things go, but I'd like to cut the stable/1.8.x
>branch and 
>> issue the alpha release by the following Friday (a week from
>today).
>>
>> New blockers:
>>
>> #24075  - Can't
>migrate 
>> contenttypes and auth to zero 
>> 
>> Owner: Simon
>> Status: This is an existing issue on 1.7, but addressing it seems
>to 
>> require (or at least, would be a lot easier) with the proposed
>new feature 
>> of adding a "plan" argument to the post_migrate() signal. There
>is a patch 
>> in the works.
>>
>> Resolved since last time:
>>
>> #23861 - 
>>  Fields referenced
>in 
>> migrations cannot be (re)moved, even if migrations have been
>squashed 
>> 
>> Owner: Tim
>> Now: I polished and committed the patch for this.
>> Last time: I committed a patch for the second ticket and will
>polish 
>> the patch for the first issue.
>>
>> Most of the issues tagged "1.8-alpha" have been completed or
>deferred. 
>> The two main ones that remain are "Case/When expressions" and
>"Allowing 
>> expressions to be used in order_by 

Re: status of 1.8 release blockers

2015-02-12 Thread Tim Graham
Status of release blockers:

#24320  Unable to serialize 
UUIDField when running dumpdata with JSON format 

Status: I wrote a failing test and will try to write a patch tomorrow if no 
one else takes a look first.

#24289  Is usage of 
many_to_one and one_to_many terms confusing for relation flags? 

Status: We are waiting for feedback/confirmation from Anssi and Russ about 
the direction to take here.

#24225  KeyError when 
migrating in 1.8a1/master@728b6fd (does not occur in 1.7.3) 

#24264  foreign key constraint 
error migrating integer pk to CharField 

Status: Markus has a patch which addresses both issues. It's in good shape 
and should be ready for commit soon.

#24282  Cannot Modify Foreign 
Keys Within Data Migrations 
Status: This is awaiting a test case to reproduce the issue (I'll 
investigate tomorrow if no one else does).

Here is the filter for 1.8 release blockers as well as issues tagged 1.8 
beta or 1.8 and thus are on my radar to make a decision on in the next 
couple days:
https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=~1.8-beta=assigned=new=~1.8=assigned=new=id=summary=status=owner=type=component=changetime=1=changetime

On Wednesday, February 4, 2015 at 9:45:33 AM UTC-5, Tim Graham wrote:
>
> Reminder that the 1.8 beta release is scheduled for twelve days from now: 
> Monday, February 16. 
>
> Please check this filter for remaining blockers for beta:
>
>
> https://code.djangoproject.com/query?status=assigned=new=1.8alpha1=Release+blocker=assigned=new=~1.8-beta=id=summary=status=owner=type=component=changetime=1=changetime
>
> I'll follow up next week to ensure we have owners for any issues that 
> remain after the weekend.
>
> On Thursday, January 15, 2015 at 8:30:04 PM UTC-5, Tim Graham wrote:
>>
>> I think master is stabilizing and the number of unsolved regressions 
>> should be ~0 by tomorrow. I'd like to release the alpha around 2100 UTC 
>> tomorrow +/- ~4 hours depending on how things go with the remaining issues. 
>> Let me know if there is anything you think needs to be in the alpha that 
>> wouldn't meet this deadline.
>>
>> On Tuesday, January 13, 2015 at 1:50:26 AM UTC-5, Tino de Bruijn wrote:
>>>
>>> Congratulations! Looks like you've steadily moved it through.
>>>
>>> Tino
>>>
>>> On Tue, Jan 13, 2015 at 3:25 AM, Tim Graham  wrote:
>>>
 We did it -- all features are in or out for alpha. Please consider 
 master frozen for new features until we cut the stable/1.8.x branch later 
 this week. Feel free to commit code cleanups and/or bug fixes until then.


 On Friday, January 9, 2015 at 1:14:02 PM UTC-5, Tim Graham wrote:
>
> Here is the fifth update with several days to go until alpha. I 
> believe we are on track for a feature freeze at the end of day on Monday. 
> Let's see how things go, but I'd like to cut the stable/1.8.x branch and 
> issue the alpha release by the following Friday (a week from today).
>
> New blockers:
>
> #24075  - Can't migrate 
> contenttypes and auth to zero 
> 
> Owner: Simon
> Status: This is an existing issue on 1.7, but addressing it seems to 
> require (or at least, would be a lot easier) with the proposed new 
> feature 
> of adding a "plan" argument to the post_migrate() signal. There is a 
> patch 
> in the works.
>
> Resolved since last time:
>
> #23861 - 
>  Fields referenced in 
> migrations cannot be (re)moved, even if migrations have been squashed 
> 
> Owner: Tim
> Now: I polished and committed the patch for this.
> Last time: I committed a patch for the second ticket and will polish 
> the patch for the first issue.
>
> Most of the issues tagged "1.8-alpha" have been completed or deferred. 
> The two main ones that remain are "Case/When expressions" and "Allowing 
> expressions to be used in order_by queryset method." Depending on what 
> progress is made over the weekend on these issues, they may or may not 
> make 
> it into 1.8.
> https://code.djangoproject.com/query?status=assigned;
> status=new=~1.8-alpha
>
> On Saturday, January 3, 2015 at 1:19:25 PM UTC-5, jdunck wrote:
>>
>> Thank you, Tim, for shepherding this.
>> On Jan 3, 2015 8:09 AM, "Tim Graham" 

Re: Formalizing template loader and debug api's

2015-02-12 Thread Preston Timmons
My pull request is updated with a simplified cache loader and docs. I also 
found
some nicer solutions to some of the hackier things, like making origin 
available
to the ExtendsNode.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa62be63-544c-4191-94a0-adc58315bd58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Abstract models and the app registry

2015-02-12 Thread Carl Meyer
On 02/11/2015 08:17 PM, Alex Hill wrote:
> I'm still curious as to why abstracts aren't registered – is that a
> requirement of some feature of the app registry design, or is it just
> that way because?

I think it's just a natural consequence of not considering them to be
real models.

One practical issue is that currently abstract models are not required
to be in an app or have an app-label / app-config at all, which I know
people take advantage of (because when we temporarily broke it after the
merge of app-loading, people complained); it would be hard to keep this
working and also add abstract models to the app-registry.

> I think what I would like to do is just declare that string references
> in related fields are only resolved in concrete models. In abstract
> models, they can just remain as string references until the fields are
> copied and contributed to concrete subclasses, at which point they'll be
> resolved normally. Then if abstract models do end up in lazy operations,
> they can be considered an anomaly just as a typo would be; we don't need
> to account for them specifically.
> 
> Can you see any problem with that approach?

That seems fine to me. I don't think anyone should be trying to do
anything with relation fields on an abstract model. In fact, I've never
seen anyone try to do anything at all with an abstract model other than
inherit from it.

> I've just implemented that change and the test suite passes – not
> surprising given that there were edge cases where this was happening
> anyway (e.g. abstract models with relations to "self").

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54DCDD29.9050302%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Feature proposal: Allow shadowing of abstract fields

2015-02-12 Thread Loïc Bistuer
Hi Marten,

Sorry for the late response, it's been a busy week. Thanks for working on this, 
I'll try to have a look at your branch this weekend.

In the meantime I'll leave some comments below.

> On Feb 12, 2015, at 22:43, Marten Kenbeek  wrote:
> 
> Current status:
>   • Models in general seem to be working.
>   • Trying to override a concrete (or explicitly locked) field with an 
> abstract field will keep the concrete field, but not raise any errors. This 
> occurs when inheriting from (AbstractBase, ConcreteBase). 
>   • I might still change this to raise an error, it migth cause a 
> few headaches when fields don't appear while they're first in the mro. 

This should definitely be an error. We recently added checks so two concrete 
parents can't have clashing fields, this is similar.

>   • Trying to override field.attname (e.g. foo_id) will fail checks 
> unless you explicitly set foo = None. 
>   • Trying to override an abstract field with a reverse relation will 
> fail checks unless you explicitly set foo = None.

That's good.

> What is still needed:
>   • ? More extensive model tests. During development a few more bugs 
> popped up. I've written tests for them, but there might be some more.
>   • Explicit migration tests. Existing migration tests pass, but don't 
> include the new scenario's.
>   • Documentation. 
> My WIP branch can be found at 
> https://github.com/knbk/django/compare/ticket_24305.
> 

> Op dinsdag 10 februari 2015 14:36:53 UTC+1 schreef Marten Kenbeek:
> Hi Aron,
> 
> With option 3, this would work:
> 
> class Cousin(models.Model):
> child = models.ForeignKey(Child, allow_override=True)
> 
> but it would raise an error without `allow_override`. 
> 
> I think my question really is: should we treat reverse relations as 
> first-class fields, or not? If we do, 1) would be the logical choice but can 
> cause problems. 3) would deal with those problems in a way and still allow a 
> relation field from another model to override a local field. If we don't, 
> that kind of implies 2). Removing the field with `None` would implicitly 
> allow a reverse relation to take its place, but that reverse relation in and 
> of itself would not be allowed to override any abstract fields. 
> 
> This is just an example. In real code this would more likely happen with an 
> explicit `related_name`. Renaming the related name and living with an unused 
> `cousin_set` attribute is the current solution, but with this feature 
> proposal it would be nice to also have a way to override the inherited field 
> and use it for a reverse relation instead. 
> 
> 
> Op dinsdag 10 februari 2015 02:28:58 UTC+1 schreef Aron Podrigal:
> Why should this be treated differently than the general behavior when 
> realted_names clash when you have more than one foreign key to the same 
> model? So as one would normally do
> set the related_name explicitly to some other value.
> setting the field to None is just the way of removing a field and has nothing 
> more special  related to the auto created reverse field descriptor.
> about option 3 I didn't quite understand. can you explain a bit more?

+1 to what Aron said.

> 
> On Monday, February 9, 2015 at 4:25:22 PM UTC-5, Marten Kenbeek wrote:
> I'd like some additional opinions on the following:
> 
> Say you have the following classes:
> 
> class Parent(models.Model):
> cousin_set = models.CharField(max_length=100)
> 
> class Meta:
> abstract = True
> 
> class Child(Parent):
> pass
> 
> class Cousin(models.Model):
> child = models.ForeignKey(Child)
> 
> Obviously, the `cousin_set` field inherited from `Parent` clashes with the 
> reverse relation from `Cousin`. 
> 
> I can see the following options:
> 1) Allow the reverse object descriptor to overwrite the field. 

No this would be very confusing.

> 2) Only allow the reverse object descriptor to overwrite the field if it is 
> explicitly set to None on the target model.

Yes but as Aron pointed out we aren't specifically "allowing" the descriptor to 
override the field, it's just that the field was already removed (through None) 
so the reverse descriptor isn't clashing with anything.

> 3) Only allow the reverse object descriptor to overwrite the field if the 
> foreignkey/m2m/o2o field itself has a flag set to explicitly override.

Let's not do that, it's clunky, I also don't like the locking mechanism 
mentioned above.

> 1) is consistent with the behaviour of local fields, but I think it will be 
> problematic if other models can silently overwrite a field. 3) would still 
> allow other models to affect local fields, but at least it has a fail-safe 
> that prevents you from accidentally overriding fields. 2) would only allow 
> the inheriting model itself to change which fields it inherits. 
> 
> Problems caused by option 1) would be hard to debug when you don't know which 
> code overrides your field, so I wouldn't do 

Re: Feature proposal: Allow shadowing of abstract fields

2015-02-12 Thread Marten Kenbeek
Current status:

   - Models in general seem to be working.
   - Trying to override a concrete (or explicitly locked) field with an 
   abstract field will keep the concrete field, but not raise any errors. This 
   occurs when inheriting from (AbstractBase, ConcreteBase). 
  - I might still change this to raise an error, it migth cause a few 
  headaches when fields don't appear while they're first in the mro. 
   - Trying to override field.attname (e.g. foo_id) will fail checks unless 
   you explicitly set foo = None. 
   - Trying to override an abstract field with a reverse relation will fail 
   checks unless you explicitly set foo = None.

What is still needed:

   - ? More extensive model tests. During development a few more bugs 
   popped up. I've written tests for them, but there might be some more.
   - Explicit migration tests. Existing migration tests pass, but don't 
   include the new scenario's.
   - Documentation. 

My WIP branch can be found at 
https://github.com/knbk/django/compare/ticket_24305.

Op dinsdag 10 februari 2015 14:36:53 UTC+1 schreef Marten Kenbeek:
>
> Hi Aron,
>
> With option 3, this would work:
>
> class Cousin(models.Model):
> child = models.ForeignKey(Child, allow_override=True)
>
> but it would raise an error without `allow_override`. 
>
> I think my question really is: should we treat reverse relations as 
> first-class fields, or not? If we do, 1) would be the logical choice but 
> can cause problems. 3) would deal with those problems in a way and still 
> allow a relation field from another model to override a local field. If we 
> don't, that kind of implies 2). Removing the field with `None` would 
> implicitly allow a reverse relation to take its place, but that reverse 
> relation in and of itself would not be allowed to override any abstract 
> fields. 
>
> This is just an example. In real code this would more likely happen with 
> an explicit `related_name`. Renaming the related name and living with an 
> unused `cousin_set` attribute is the current solution, but with this 
> feature proposal it would be nice to also have a way to override the 
> inherited field and use it for a reverse relation instead. 
>
>
> Op dinsdag 10 februari 2015 02:28:58 UTC+1 schreef Aron Podrigal:
>>
>> Why should this be treated differently than the general behavior when 
>> realted_names clash when you have more than one foreign key to the same 
>> model? So as one would normally do
>> set the related_name explicitly to some other value.
>> setting the field to None is just the way of removing a field and has 
>> nothing more special  related to the auto created reverse field descriptor.
>> about option 3 I didn't quite understand. can you explain a bit more?
>>
>> On Monday, February 9, 2015 at 4:25:22 PM UTC-5, Marten Kenbeek wrote:
>>>
>>> I'd like some additional opinions on the following:
>>>
>>> Say you have the following classes:
>>>
>>> class Parent(models.Model):
>>> cousin_set = models.CharField(max_length=100)
>>>
>>> class Meta:
>>> abstract = True
>>>
>>> class Child(Parent):
>>> pass
>>>
>>> class Cousin(models.Model):
>>> child = models.ForeignKey(Child)
>>>
>>> Obviously, the `cousin_set` field inherited from `Parent` clashes with 
>>> the reverse relation from `Cousin`. 
>>>
>>> I can see the following options:
>>> 1) Allow the reverse object descriptor to overwrite the field. 
>>> 2) Only allow the reverse object descriptor to overwrite the field if it 
>>> is explicitly set to None on the target model.
>>> 3) Only allow the reverse object descriptor to overwrite the field if 
>>> the foreignkey/m2m/o2o field itself has a flag set to explicitly override.
>>>
>>> 1) is consistent with the behaviour of local fields, but I think it will 
>>> be problematic if *other *models can silently overwrite a field. 3) 
>>> would still allow other models to affect local fields, but at least it has 
>>> a fail-safe that prevents you from accidentally overriding fields. 2) would 
>>> only allow the inheriting model itself to change which fields it inherits. 
>>>
>>> Problems caused by option 1) would be hard to debug when you don't know 
>>> which code overrides your field, so I wouldn't do that. I think 2) would be 
>>> the cleanest and most consistent way. Only local fields would override 
>>> parent fields, but the sentinel value `None` would remove the field and 
>>> free the name for reverse relations. I can also see the advantage of 3) 
>>> over 2) when you don't have access to the model on the other side. However, 
>>> I don't know enough about foreign key internals to know if 3) is at all 
>>> feasible. What happens e.g. when only the target is loaded in a migration? 
>>> Would it pick up that the remote foreign key overrides a local field? As 
>>> adding reverse relations is a lazy, or at least delayed operation afaik, 
>>> would it still be save to rely on that to override fields?
>>>
>>> I believe my current plans for the patch 

Re: Django inlineformset autocomplete and autopopulate by ajax

2015-02-12 Thread Raúl
Hi Ajay,

Thanks for contacting us and using Django. This list is to discuss about Django 
development itself. Discuss bugs, new features that can be added to the 
language. To discuss how to use Django or when having issues using you should 
use the list django-users@google groups.com

You will find help there.

Kind Regards,
Raúl

> On 12 Feb 2015, at 07:29, Ajay Kumar  wrote:
> 
> I'm trying to do this following link feature in django,
> http://demo.smarttutorials.net/jquery-autocomplete/
> 
> Here by choosing country the rest of the fields will be auto populated, like 
> this i'm trying to achieve in django, If any idea pls tell me it will be very 
> great for me
> 
> 
> This is Product table,by this i will add many products
> models.py
> 
> class Product(models.Model):
>   store   =   models.ForeignKey(Store)
>   code=   
> models.CharField(verbose_name='Product Code', max_length=128, blank=False)
>   name=   
> models.CharField(verbose_name='Product Name', max_length=128, blank=False)
>   unit_price  =   
> models.FloatField(verbose_name='Unit Price', blank=False)
>   in_stock=   
> models.IntegerField(verbose_name='In Stock', default=0, blank=False)
> 
> 
> 
> This is Invoice order table, in this i will get customer details
> 
> class Invoice(models.Model):
>   customer=   
> models.ForeignKey(Customer)
>   date=   
> models.DateTimeField(auto_now=True, blank=False)
> 
> This in Invoice Item order table which is in inline formset 
> 
> class InvoiceItem(models.Model):
>   invoice =   
> models.ForeignKey(Invoice)
>   product =   
> models.ForeignKey(Product)
>   particular  =   
> models.CharField(verbose_name='Particular', max_length=128, blank=False)
>   quantity=   
> models.IntegerField(verbose_name='Quantity', default=0)
>   unit_price  =   
> models.FloatField(verbose_name='Unit Price', blank=False)
>   tax_rate_percentage =   models.FloatField(verbose_name='Tax 
> Rate Percentage', blank=False)
> 
> 
> 
> views.py
> 
> I'm trying to raise invoice by autopopulate feature.
> def add_invoice(request):
>   store = Store.objects.get(id=pk)
>   product = Product.objects.filter(store=store)
>   context =  RequestContext(request)
>   InvoiceItemInlineFormSet = inlineformset_factory(Invoice, InvoiceItem, 
> extra = 1,exclude=('invoice',))
>   if request.method == 'POST':
>   invoiceform = InvoiceForm(request.POST)
>   invoiceformset =  InvoiceItemInlineFormSet(request.POST)
>   if invoiceform.is_valid() and invoiceformset.is_valid():
>   invoice = invoiceform.save(commit=False)
>   invoice.store = store
>   invoice.save()
>   invoiceformset.save(commit=False)
>   invoiceformset.instance = invoice
>   invoiceformset.save()
>   return 
> HttpResponseRedirect('/store_invoice/%s/invoice/'% pk)
>   else:
>   invoiceform = InvoiceForm()
>   invoiceformset =  InvoiceItemInlineFormSet()
>   args = {}
>   args.update(csrf(request))
>   args = {'email':email,'store':store,'invoiceform':invoiceform, 
> 'invoiceformset':invoiceformset}
>   return render_to_response('invoice/invoice_add.html',args,context)
> 
> invoice_add.html
> 
> {% extends "base_site.html" %}
> {% load staticfiles %}
> {% block title %}Add New Order | Finvoicez{% endblock %}
> {% block page-heading %}Add New Order{% endblock %}
> {% block content %}
> 
> 
> $(function() {
> $(".inline.{{ invoiceformset.prefix }}").formset({
> prefix: "{{ invoiceformset.prefix }}",
> })
> })
> 
> 
> {% 
> csrf_token %}
> 
> 
> Customer
> {{invoiceform}}
> 
> 
> 
> Order Items
> {{ invoiceformset.management_form }}
> {{ invoiceformset.non_form_errors }}
> {% for form in invoiceformset %}
> {{ form.id }}
> 
> {{form}}
> 
> {% endfor %}
> 
> Add Order
> 
> 
> {% endblock %}
> 
> Here i'm trying to bring when i'm adding Invoice Item , by selecting the 
> product code the rest of fields want to be auto populate by corresponding 
> Product details(Particular,unit price and tax) and it must be in 
> inlineformset, for every 'add another' it must be auto populate, like 

Re: Bytecode in Migrations

2015-02-12 Thread Stan
I noticed the same pb yesterday (runserver exception) when doing some git 
bisect on django repo because of some pyc content_type migration file. 
Removing the pyc files after each git bisect good|bad fixed the issue.

On Thursday, February 12, 2015 at 1:19:32 AM UTC+1, Andrew Godwin wrote:
>
> Your problem is likely that the pyc file for the new initial migration 
> somehow seems newer than the py file and so Python is using it over the new 
> source file.
>
> I'm not sure how this happens if it's a new migration, but I've seen it 
> happening when switching git branches before. We have pyc files turned off 
> in dev to stop this.
>
> Andrew
> On 11 Feb 2015 21:05, "abhillman"  
> wrote:
>
>> I have gotten bitten by lingering bytecode in migrations on several 
>> occasions. Steps to reproduce are a little bit complex, but here is an 
>> rough example:
>>
>> Local Box:
>> — have *.pyc rule in .gitignore
>> — create some migrations
>> — commit them
>>
>> Server Box:
>> — pull repository
>> — execute migrations
>>
>> Local Box:
>> — remove migrations
>> — commit
>> — create new initial migration
>>
>> Server Box:
>> — pull repository
>> — remove migrations history from db
>> — run fake initial migration — get an error here
>>
>> At this point, the server box has a migrations directory that looks 
>> something like this (bytecode is still around because it was in the 
>> gitignore):
>> — migrations 
>> — __init__.py
>> — 0001_initial.py
>> — 0001_initial.pyc
>> — 0002_second.pyc
>> — 0003_third.pyc
>>
>> When running "python manage migrate" the bytecode appears to be 
>> referenced, which often causes errors when running the migrations. When 
>> using git, for example "git clean -df" clears out the problem. What I am 
>> wondering is if it might make sense to make a deliberate attempt to ignore 
>> bytecode without accompanying *.py files. This appears to be an issue 
>> because of the way that migrations dynamically import python code, but I am 
>> not sure. Perhaps the problem is more subtle as I am not deeply familiar 
>> with the way that migrations work.
>>
>> aryeh
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1dbf1434-b24a-47c9-b45b-ae04530d7867%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 developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bf96de70-686e-45b8-9f5c-d472f484c656%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.