date:20140928

Change GFK to FK

2014-09-28 Thread carlos

Hi, is posible to change GenericForeingnKey to ForeignKey without losing
data?

any link to explain the trick?

I have an old application with GFK but now I want to FK moment but I will
not lose data

this is example my models old and below the new models

http://pastebin.com/ym6Scrmd

Cheers

-- 
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/CAM-7rO0HPMFAOReqOZ0ym%2B1r8QBh_1Z5hA%2BGhYNp8sWUa95gjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best way to use a 'all' QuerySet as a dict with id first

2014-09-28 Thread aRkadeFR

Thanks for the answer, I just wondered if there was a built-in solution in
Django.

On 27/09/14 06:01, tkdchen wrote:
> 
> 
> On Saturday, September 27, 2014 9:06:58 PM UTC+8, aRkadeFR wrote:
> >
> > @James Brewer: 
> > If I change my code, I can have this user_ids list. 
> > btw, it's filter and not get if you're searching multiple objects (the 
> > user_ids). 
> >
> > @Alejandro Varas G.: 
> > That doesn't change the fact that 'User.objects.get(id=X)' will hit the 
> > database everytime. 
> >
> > Right now, the problem is solved, by creating the AllUserSet, but I think 
> > my 
> > code is pretty ugly, and it seems strange to me that the ORM can't handle 
> > that 
> > built-in, by caching the .all() or .filter(id__in=users_ids) 
> >
> >
> Django actually caches all objects fetched when it evaluates .all or 
> .filter method. The problem you are facing is that how to reuse the cached 
> objects efficiently to avoid hitting database with unnecessary SQL queries. 
> James gave you a good solution. Based on his solution, you don't need to 
> call the `get' method each time getting user by id. Just iterate users 
> object and find the right one by comparing id.
> 
> 
>  
> 
> > The ideally solution would be something like: 
> >
> > AllUser = User.objects.all() 
> >
> > for i in user_id: 
> > AllUser.get(id=i) 
> >
> >
> This piece of code would be changed to
> 
> AllUser = User.objects.all()
> for i in user_id:
> for user in AllUser:
> if user.pk == i:
> print 'find the user'
> 
> or, even you may construct AllUser to dict to simplify the search
> 
> AllUser = dict((user.pk, user) for user in User.objects.all()) # Here, hit 
> db, only once
> for i in user_id:
> user = AllUser.get(i, None) # search by id in memory
> if user is not None:
> print 'find the user'
> 
> Hope, this could help you. 
> 
> But this code hits the database every time the 'get' is called. 
> >
> >
> > On 26/09/14 12:36, James Brewer wrote: 
> > > Do you have a single list of the IDs you want? If so, you can do 
> > something 
> > > like `User.objects.get(id__in=user_ids)`. This will fetch all Users 
> > whose 
> > > `id` is in some list `user_ids`. 
> > > 
> > > Does that help? 
> > > 
> > > Happy hacking! 
> > > 
> > > James 
> > > 
> > > On Fri, Sep 26, 2014 at 11:43 AM, Alejandro Varas G.  > > 
> > > wrote: 
> > > 
> > > > Hi, 
> > > > 
> > > > You should use User.objects.get(id=X) 
> > > > 
> > > > Best 
> > > > El 26/09/2014 15:28, "aRkadeFR"  
> > escribió: 
> > > > 
> > > > > 
> > > > > Hey! 
> > > > > 
> > > > > I'm having a hard time trying to reduce the number of SQL queries on 
> > a 
> > > > view. 
> > > > > 
> > > > > Basically, I'm fetching all my User, with User.objects.all(), and 
> > save 
> > > > this 
> > > > > queryset as AllUser. 
> > > > > 
> > > > > Then every time I need to get the user with the id = X , I'm calling 
> > a 
> > > > function 
> > > > > 'get_user_from_id', that iterate over the AllUser queryset variable, 
> > and 
> > > > when 
> > > > > it finds the id, returns it. 
> > > > > 
> > > > > I considerably reduced the number of SQL queries, but I would like 
> > to 
> > > > know if 
> > > > > you think of a better way? 
> > > > > 
> > > > > Thank you 
> > > > > 
> > > > > -- 
> > > > > 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/20140926182939.GA26744%40rkade-thinkpad
> >  
> > > > . 
> > > > > 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...@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/CAL60nj%2BBtqs9CXu8drOiWPoJ7aUkAKjLqXKCxmR_TMTeOOH%3DGw%40mail.gmail.com
> >  
> > > > <
> > https://groups.google.com/d/msgid/django-users/CAL60nj%2BBtqs9CXu8drOiWPoJ7aUkAKjLqXKCxmR_TMTeOOH%3DGw%40mail.gmail.com?utm_medium=email_source=footer>
> >  
> >
> > > > . 
> > > > 
> > > > For more options, visit https://groups.google.com/d/optout. 
> > > > 
> > > 
> > > 
> > > 
> > > -- 
> > > James Brewer 
> > > jamesbrewer.io 
> > > 
> > > -- 
> > > You

Re: Django Generic Create VIew and Hidden fields

2014-09-28 Thread Tom Evans

On Sun, Sep 28, 2014 at 5:49 PM, Sabine Maennel
 wrote:
> Can someone please help me with Create View? I have a hidden field and not
> having it in the form causes Django to not store my object in the database.
> It fails silently.
>
> So here are my files:
>
> model.py:
> class Application(TimeStampedModel):
> name = models.CharField(max_length=50)
> application_status = models.CharField(max_length=1,
> choices=APPLICATION_STATUS, default=APPLICATION_NEW)
>
> def __unicode__(self):
> return self.name
>
> def save(self):
> self.application_status ==self.APPLICATION_NEW

This overwritten save method is probably at fault - it does not ever
actually save the model or call the parent class to do so either.

Cheers

Tom

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

Django Generic Create VIew and Hidden fields

2014-09-28 Thread Sabine Maennel

Can someone please help me with Create View? I have a hidden field and not 
having it in the form causes Django to not store my object in the database. 
It fails silently.

So here are my files: 

*model.py:*
class Application(TimeStampedModel):
name = models.CharField(max_length=50)
application_status = models.CharField(max_length=1, 
choices=APPLICATION_STATUS, default=APPLICATION_NEW)

def __unicode__(self):
return self.name

def save(self):
self.application_status ==self.APPLICATION_NEW

def get_absolute_url(self):
return reverse('application:detail', kwargs={'pk': self.pk})

*forms.py*
class ApplicationForm(ModelForm):

class Meta:
model = Application
exclude = ('date_created', 'date_updated', 'application_status')


*models.py*
class ApplicationCreateView(CreateView):
template_name = 'application/create_application.html'
form_class = ApplicationForm

def get_success_url(self):
try:
application = Application.objects.get(id=self.object.id)
except:
return reverse('application:failed')
else:
return reverse('application:received')

def __init__(self, *args, **kwargs):
self.application_status = Application.APPLICATION_NEW
super(ApplicationCreateView, self).__init__(*args, **kwargs)

def save(self, commit=True):
self.instance.application_status = Application.APPLICATION_NEW
return super(ApplicationCreateView, self).save(commit)


Ich hoffe auf Hilfe, vielen Danke im Voraus
   Sabine

-- 
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/75ce0033-9563-4611-9d46-3b32fc31dc25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 and Python 2.6

2014-09-28 Thread François Schiettecatte

Russell

Thanks, this the answer I was looking for, I think virtualenv is the way to go.

Cheers

François

On Sep 27, 2014, at 7:14 PM, Russell Keith-Magee  
wrote:

> 
> Out of the box, it won't work - but if maintaining an internal fork that adds 
> Python 2.6 compatibility back in shouldn't be *too* difficult. 
> 
> When we drop support for a Python version, we don't go out of our way to 
> break compatibility with that version. It's more like a gradual process where 
> language features incompatible with older versions of Python slowly drift 
> into the codebase.
> 
> The two sources of problems you'll hit are:
> 
>  1) Using language features available in 2.7 that weren't in 2.6. Set 
> literals, dictionary/set comprehensions, and multiple context managers are 
> the new features that are most likely to cause problems.
> 
>  2) Relying on compatibility shims that are no longer required in 2.7, and so 
> were removed. The native OrderedDictionary type will be the complication 
> here. We previously shipped a shim for older Python versions; that shim was 
> removed in Django 1.7.
> 
> If you're absolutely stuck on 2.6, and you can't use a virutalenv or docker 
> container to isolate your Python requirements (as suggested by others in this 
> thread), then a back port might be an option.
> 
> The ultimate test - Can you run Django's own test suite? Once the test suite 
> runs, you shouldn't have any problems.
> 
> Yours
> Russ Magee %-)
> 
> On Sun, Sep 28, 2014 at 2:54 AM, François Schiettecatte 
>  wrote:
> Hi
> 
> I know that Django 1.7 does not officially run on Python 2.6:
> 
> 
> https://docs.djangoproject.com/en/1.7/releases/1.7/#python-compatibility
> 
> Unfortunately I am stuck with Python 2.6 on a number of servers but would 
> like to migrate to Django 1.7. Does anyone run that configuration? Is there 
> anything in Django 1.7 which explicitly prevents it from running on Python 
> 2.6? Or is this a "great if it runs, but don't care if it doesn't" situation.
> 
> Cheers
> 
> François
> 
> 
> --
> 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/04A8E7D2-35CD-429A-873F-FF20C4D3D492%40gmail.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/CAJxq84-MEYEN_fX6f2Sj%3DguLB-jp%3D9GKvw36o9CRbG4GDSX_aQ%40mail.gmail.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/F0A55A4F-C988-4C32-9C01-5A6782F3755A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: Upgrading Django (to 1.7)

2014-09-28 Thread bobhaugen

Fred, thanks a jillion for the excellent advice! I obviously missed that 
bit in the data migration boilerplate.

On Saturday, September 27, 2014 9:29:10 AM UTC-5, Fred Stluka wrote:
>
>  Bob,
>  
> Are you referring directly to the models by name in the data 
> migrations?  That could be the problem, because yes, the migration
> would be using the latest models at the time that the migration is
> executed, not the models as they stood at the time that the 
> migration was written.
>
> There's a warning in a comment in the boilerplate code generated
> for each data migration by the command:
> % manage datamigration  
>
> It says:
>
> def forwards(self, orm):
> "Write your forwards methods here."
> # Note: Don't use "from appname.models import ModelName". 
> # Use orm.ModelName to refer to models in this application,
> # and orm['appname.ModelName'] for models in other applications.
>
> and there is a dictionary of the models as they existed at that
> time shown later in the same file.
>
> If you always follow this advice and manipulate orm.ModelName 
> instead of appname.models.ModelName, it should solve exactly 
> the problem you are describing.
>
> Hope this helps,
> --Fred 
> --
> Fred Stluka -- mailt...@bristle.com  -- 
> http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates. 
> --
>  
> On 9/27/14 10:00 AM, bobhaugen wrote:
>  
> The problem we ran into was not with the order of migrations, it was that 
> all of the migrations were running with the latest models.py code. The data 
> migration was trying to move data from one model field to another model 
> field, and the "from" field had been deleted from models.py.  
>
> This was awhile ago, and my memory might be faulty. Do the latest 
> migrations give you any way to deal with that situation? I mean, do they 
> migrate the models in models.py in sync with the the database schema 
> migrations? 
>
> I can see where a data migration might work in a schema migration sequence 
> if you expressed it all in SQL, just dealing with the database alone, but 
> we of course wrote in Python using the Django ORM.
>
> On Friday, September 26, 2014 10:04:49 AM UTC-5, Fred Stluka wrote: 
>>
>>  Bob,
>>
>> You can control the order in which migrations run.
>>
>> For South, see "depends_on" and "needed_by":
>> - http://south.readthedocs.org/en/latest/dependencies.html
>>
>> For Django 1.7 migrations, see "dependencies":
>> - https://docs.djangoproject.com/en/dev/topics/migrations/#dependencies
>>
>> --Fred 
>> --
>>
>>
>
>  
>  

-- 
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/ddd6b3c9-71ba-4396-8c1d-9558eefd815a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Change GFK to FK

Re: Best way to use a 'all' QuerySet as a dict with id first

Re: Django Generic Create VIew and Hidden fields

Django Generic Create VIew and Hidden fields

Re: Django 1.7 and Python 2.6

Re: Re: Upgrading Django (to 1.7)

6 matches

Site Navigation

Mail list logo

Footer information