Re: Migrations During Development

[Carl Meyer]

On 04/25/2015 05:18 PM, Carl Meyer wrote:
> You can use the "squash" feature [1] to squash a set of historical
> migrations down to a single migration.

Forgot this link:
https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

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


signature.asc
Description: OpenPGP digital signature

Re: Migrations During Development

[Carl Meyer]

On 04/25/2015 11:28 AM, Timothy W. Cook wrote:
> if you don't store migrations, then you have to generate them on each
> production update, right?  if so, wouldn't they count as untested
> code?  how about manually tweaked, or data migrations?
> 
> 
> ​That will certainly be true once you start using a staging or
> production server.  
> But before they they are just a kind left over creative ideas.  :-)  Not
> really useful for anything in the future, AFAICS. 

If you only have one deployment (your local machine), you can erase all
your migrations and "start over" anytime with a new initial migration,
with no problems.

Once you have additional deployments (either other developers' machines,
or staging or production deployments), you shouldn't remove or change
any migrations that have been pushed to those other deployments.

You can use the "squash" feature [1] to squash a set of historical
migrations down to a single migration. This requires a phased
deployment, where you first push out a version including both the new
squashed migration and all the old replaced migrations, and then later
(once you are confident all deployments are up to date) you can safely
remove the old replaced migrations.

It's also true that if you have a series of new migrations locally that
haven't yet been pushed to any other deployment, you can delete and
replace them with a single migration before pushing.

It's very much like VCS commits: it's ok to edit your local history, but
you have to be a lot more careful with history that you've already
shared with others.

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


signature.asc
Description: OpenPGP digital signature

Re: Migrations During Development

[Carl Meyer]

On 04/25/2015 11:15 AM, Javier Guerra Giraldez wrote:
> On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cook 
> wrote:
>> 
>> On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt
>>  wrote:
>>> 
>>> Are you using version control like GIT? I save the migration
>>> folder with the __init__.py in GIT, nothing else, because al the
>>> migrations will be diferent in the diferent servers.
>>> 
>> 
>> This is probably what I should have done. I have been saving them
>> all to the git repo.
> 
> 
> with South i used to save them to the repo too and push whole to 
> production.  haven't tried Django migrations yet; is there any 
> difference that make this more appropriate?
> 
> if you don't store migrations, then you have to generate them on
> each production update, right?  if so, wouldn't they count as
> untested code?  how about manually tweaked, or data migrations?

Migrations should be committed to VCS in both South and in Django
migrations.

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


signature.asc
Description: OpenPGP digital signature

Re: Migrations During Development

[Carl Meyer]

On 04/25/2015 06:48 AM, Jorge Andrés Vergara Ebratt wrote:
> Are you using version control like GIT? I save the migration folder with
> the __init__.py in GIT, nothing else, because al the migrations will be
> diferent in the diferent servers.

This is not a good idea. Migrations should be committed to git, and
should be the same on all deployments. Otherwise they do not serve their
purpose of ensuring that all deployments end up with the same database
schema.

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


signature.asc
Description: OpenPGP digital signature

Python suds with Keystore

[nadaei...@gmail.com]

HI All,

I am trying to consume wsdl with suds using keystore i am getting forbiden
since suds is not including the keystore in the request:

co = Client('https://10.102.5.81:901/APIService.svc?singleWsdl')



co.options.wsse.keystore = Keystore()

co.options.wsse.keystore.addKey(RsaPemFilePrivateKey(
'certificate.pem'), X509PemFileCertificate('cag1.pem'))



response11 =  co.service.Login(clientID=int(202), terminalID=
'657CBC06-B339-432C-8122-F8DE3DDD15A8', opName='API-0002', password='123456'
)

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

Re: Migrations During Development

[Abhaya Agarwal]

Hi Timothy,

Assuming as an example that 0002_<>.py is the migration that you have
already applied to production server, this is the scheme I follow:

   - Make sure you have your local db up to date i.e. all the model changes
   have been applied to database.
   - Fake a reversal to the last migration already applied to prod. In this
   case: manage.py migrate --fake  0002
   - delete all the migration files after 0002
   - run makemigrations: manage.py makemigrations
   - Fake application of the new single migration: manage.py migrate --fake
   

Now you have a single migration representing all the db changes since the
last deploy. Hope this helps.

Regards,
Abhaya

On Sat, Apr 25, 2015 at 5:56 PM, Timothy W. Cook  wrote:

> Django 1.8  Python 3.4 PostgreSQL 9.3
>
> During development I am creating several migrations. It seems unnecessary
> to keep these since they only exist on my dev machine.
> Any data that I have created can be thrown away too.
>
> Is it safe to delete these migrations  (and the database) before deploying
> to the next stage for testing by users?
>
>
> --
>
> 
> Timothy Cook
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> MLHIM http://www.mlhim.org
>
>  --
> 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%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-
blog: http://abhaga.blogspot.com
Twitter: http://twitter.com/abhaga
-

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

Re: Admin Inlines

[Timothy W. Cook]

For reference.  My mistake is that I really have a ManyToMany relationship
and I used this
http://www.mc706.com/tip_trick_snippets/18/django-manytomany-inline-admin/
to solve the problem.

Thanks to Ryan McDevitt.




On Sat, Apr 25, 2015 at 3:11 PM, Timothy W. Cook  wrote:

> The usage of AdminInlines seems backwards to me.
>
> At least in the use case I have.
>
> I have two  models:
>
> DvInterval:
> lower = models.CharField(max_length=110)
> upper = models.CharField(max_length=110)
> ...
>
>
>  ReferenceRange:
> ​  ​
> ​ ​   ...
>
> ​data_range = models.ForeignKey(DvInterval)
>
>
>
> ​Since a ReferenceRange may have many DvIntervals defined I would like to
> be able to edit them on the ReferenceRange admin page in a StackedInline.
> ​
> Kind of makes sense, right?  Add the intervals for this range.  At least
> that is what my users want.
>
> But the functionality of inlines wants me to put the ReferenceRange(s) on
> the DvIntervals page.  Most intervals will only be on one ReferenceRange
> but a ReferenceRange may have several intervals.
>
> Where is my modeling mistake?
>
> Thanks.
>
>
>
>
>
>
> 
> Timothy Cook
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> MLHIM http://www.mlhim.org
>
>


-- 


Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

-- 
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%2B%3DOU3VBk%2BKnFEUiBsVZ-r32ZEW75K0b_RgqZHheBTY2ik%2BDtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Admin Inlines

[Timothy W. Cook]

The usage of AdminInlines seems backwards to me.

At least in the use case I have.

I have two  models:

DvInterval:
lower = models.CharField(max_length=110)
upper = models.CharField(max_length=110)
...


 ReferenceRange:
​  ​
​ ​   ...

​data_range = models.ForeignKey(DvInterval)



​Since a ReferenceRange may have many DvIntervals defined I would like to
be able to edit them on the ReferenceRange admin page in a StackedInline.
​
Kind of makes sense, right?  Add the intervals for this range.  At least
that is what my users want.

But the functionality of inlines wants me to put the ReferenceRange(s) on
the DvIntervals page.  Most intervals will only be on one ReferenceRange
but a ReferenceRange may have several intervals.

Where is my modeling mistake?

Thanks.







Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

-- 
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%2B%3DOU3WHUs_rgzf0ZJcnKmw0M-6SemsC_C0tN79DTpwqeA-NLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations During Development

[Javier Guerra Giraldez]

On Sat, Apr 25, 2015 at 12:28 PM, Timothy W. Cook  wrote:
> On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez 
> wrote:
>> if you don't store migrations, then you have to generate them on each
>> production update, right?  if so, wouldn't they count as untested
>> code?  how about manually tweaked, or data migrations?
>
> That will certainly be true once you start using a staging or production
> server.
> But before they they are just a kind left over creative ideas.  :-)  Not
> really useful for anything in the future, AFAICS.


South used to have a feature to "flatten" migrations (i never tried
it, so don't know exactly how that worked).

maybe a middle point between "don't save, generate at each server" and
"save everything, get the same whole story everywhere" would be to do
this before commit (or before merging to trunk):

- revert migration directories to the currently deployed point.

- revert development database to the same point (maybe pulling the
current schema from production/staging)

- make (and test) a single migration

- commit everything.


-- 
Javier

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

Re: Migrations During Development

[Timothy W. Cook]

On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez 
wrote:

>
>

> with South i used to save them to the repo too and push whole to
> production.  haven't tried Django migrations yet; is there any
> difference that make this more appropriate?
>
>
​Hmmm, good question. That was kind of my question. With South I always
saved them.  This is my first project with using Django migrations.  There
doesn't seem to be much difference. ​



> if you don't store migrations, then you have to generate them on each
> production update, right?  if so, wouldn't they count as untested
> code?  how about manually tweaked, or data migrations?
>
>
​That will certainly be true once you start using a staging or production
server.
But before they they are just a kind left over creative ideas.  :-)  Not
really useful for anything in the future, AFAICS.

​






Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

-- 
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%2B%3DOU3VL4HEPW%2BFLAgRsh0Qfhk_Kh98%2BtO%3DyG1wN%3Dy0-C1n%3DJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations During Development

[Javier Guerra Giraldez]

On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cook  wrote:
>
> On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt 
>  wrote:
>>
>> Are you using version control like GIT? I save the migration folder with the 
>> __init__.py in GIT, nothing else, because al the migrations will be diferent 
>> in the diferent servers.
>>
>
> This is probably what I should have done. I have been saving them all to the 
> git repo.


with South i used to save them to the repo too and push whole to
production.  haven't tried Django migrations yet; is there any
difference that make this more appropriate?

if you don't store migrations, then you have to generate them on each
production update, right?  if so, wouldn't they count as untested
code?  how about manually tweaked, or data migrations?

-- 
Javier

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

Re: Migrations During Development

[Timothy W. Cook]

On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt <
javebr...@gmail.com> wrote:

> Are you using version control like GIT? I save the migration folder with
> the __init__.py in GIT, nothing else, because al the migrations will be
> diferent in the diferent servers.
>
>
​This is probably what I should have done. I have been saving them all to
the git repo.

I will likely delete them from git before I start deploying to other
machines and setup git to not track anything except the __init__.py

​





> On Sat, Apr 25, 2015, 7:45 AM Filipe Ximenes 
> wrote:
>
>> You should keep all project migrations, they will be used to update the
>> database everytime a change is made. This applies to your local project,
>> the staging server (if you have one) and your production server.
>> If you are worried about having to many migrations, you can delete the
>> ones that were not applied in other machines, and generate a single one
>> with all the changes.
>>
>> About the database, it can be deleted, but you don't need to do this,
>> your database data should only exist in your computer and not in the Django
>> project you are deploying.
>>
>> On Sat, Apr 25, 2015 at 9:26 AM, Timothy W. Cook  wrote:
>>
>>> Django 1.8  Python 3.4 PostgreSQL 9.3
>>>
>>> During development I am creating several migrations. It seems
>>> unnecessary to keep these since they only exist on my dev machine.
>>> Any data that I have created can be thrown away too.
>>>
>>> Is it safe to delete these migrations  (and the database) before
>>> deploying to the next stage for testing by users?
>>>
>>>
>>> --
>>>
>>> 
>>> Timothy Cook
>>> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
>>> MLHIM http://www.mlhim.org
>>>
>>>  --
>>> 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%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>>
>> *Filipe Ximenes*+55 (81) 8245-9204
>>
>> *Vinta Software Studio*http://www.vinta.com.br
>>
>> --
>> 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/CAA-QWB2RW_39b-8nm0Jm%2BAg9%2Bc%3DV0F4%3Dnm%3D%2B3DM7U-f3njV%3DNw%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/CAAeX05H23hsbciqm%3DXn-PgcGpsA-ezL2Pnx4joP6rWJ%2Bkeirgw%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 


Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

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

Re: Concept of partial views to be resolved from other views or template tags

[Stephan Herzog]

Thanks for your reply. We are actually using ESIs in one place or another 
and one of the projects I have in mind for refactoring currently uses ESI 
to achieve something similar. Varnish however is an additional layer on the 
server that in many of our cases is not really necessary (as in either not 
easily available, not maintainable or simply not justified for the amount 
of traffic). But more than that I think it is not suitable as a default 
when developing something with reusability in mind. I feel that users of a 
package are still free to include the partials through ESI or SSI, if their 
stack provides that option. But if not then maybe (or maybe not) the 
outlined code would be an option.

-- 
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/e4db32b1-b762-4140-ac1e-f3cad06ed251%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin should really support Twitter Bootsrap

[Derek]

I am a satisfied user of django-suit.  Right now there is beta-testing 
going on of the upgrade from Bootstrap 2 to 3...

On Wednesday, 15 April 2015 15:45:36 UTC+2, bobhaugen wrote:
>
> On Monday, April 13, 2015 at 5:16:40 PM UTC-5, Patrick Lemiuex wrote:
>>
>> It's about time, the django admin tool should support twitter bootstrap 
>> markups and styling. This is the third django project where I've had to 
>> deal with custom form widgets because the admin tool supports kind of an 
>> outdated layout scheme in the admin template.
>>
>> This also affects a lot of third party apps as well. It would be 
>> something worth contributing to the community by me.
>>
>
> You don't like any of these?
> https://www.djangopackages.com/grids/g/admin-interface/ 
>

-- 
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/095487c4-f1e7-4ad5-b4c3-095987242e74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: importing csv data into database

[Andrew Farrell]

Ah, I suppose that bit didn't get sent. Google groups only lets mail from
my old gmail address through and bounces mail from the MIT address I use by
default.

I noticed something else about your code: you are assigning 2-tuples to all
of your data types rather than strings when you do
   data.PersonID=row[0],
   data.FirstName=row[1],
   data.LastName=row[2],
   data.Address=row[3],

You might actually be aware of this, but I once spent 4 hours debugging
before I realized this on a previous project.
weapons = ('fear', 'surprise', 'fanatical devotion to the pope',)
clearly creates a 3-item tuple. But so does
weapons = 'fear', 'surprise', 'fanatical devotion to the pope',
and in fact
weapons = 'fear',
creates a 1-item tuple.

On Sat, Apr 25, 2015 at 7:27 AM, sum abiut  wrote:

> Ok , i manage to figure out where the error was coming from in my view.py
> on line  readata=csv.reader(csvfile,delimiter=';', quotechar='|'). The*
> delimiter =';'* i change the semicolon to  a comma The* delimiter =','*
> and it works.
>
> However when the data are imported from the csv file to the model it also
> write some funny character to the model as shown on the image below. How to
> import data to model without writing this funny characters?  i want the
> data to be clean
>
>
> [image: Inline image 1]
>
>
>
> view.py
> def readcsvfile(request):
> with open('/var/www/html/webapp/csvupload/data.csv','rb') as csvfile:
> readata=csv.reader(csvfile,delimiter=';', quotechar='|')
> #readata=csv.reader(csvfile)
> for row in readata:
> data=test()
> data.PersonID=row[0],
> data.FirstName=row[1],
> data.LastName=row[2],
> data.Address=row[3],
> data.save()
> return render_to_response('csv_test.html',locals())
>
>
>
>
> On Fri, Apr 24, 2015 at 4:36 PM, Andrew Farrell 
> wrote:
>
>> You might have to make sure that my indentation there is correct.
>>
>> Also, I noticed something else about your code: you are assigning
>> 2-tuples to all of your data types rather than strings when you do
>>data.PersonID=row[0],
>>data.FirstName=row[1],
>>data.LastName=row[2],
>>data.Address=row[3],
>>
>> You might actually be aware of this, but I once spent 4 hours debugging
>> before I realized this on a previous project.
>> weapons = ('fear', 'surprise', 'fanatical devotion to the pope',)
>> clearly creates a 3-item tuple. But so does
>> weapons = 'fear', 'surprise', 'fanatical devotion to the pope',
>> and in fact
>> weapons = 'fear',
>> creates a 1-item tuple.
>>
>> On Fri, Apr 24, 2015 at 12:33 AM, Andrew Farrell 
>> wrote:
>>
>>> could you replace your function with
>>> def readcsvfile(request):
>>> with open('/var/www/html/webapp/csvupload/data.csv','rb') as
>>> csvfile:
>>> readata=csv.reader(csvfile,delimiter=';', quotechar='|')
>>> #readata=csv.reader(csvfile)
>>> for i, row in enumerate(readata):
>>> try:
>>> data=test()
>>> data.PersonID=row[0],
>>> data.FirstName=row[1],
>>> data.LastName=row[2],
>>> data.Address=row[3],
>>> data.save()
>>> except Exception, e:
>>> import pdb;pdb.set_trace()
>>> print i
>>> print row
>>> print row[1]
>>> raise e
>>> return render_to_response('csv_test.html',locals())
>>>
>>> And then re-run this again? When you hit the offending row of data, it
>>> should pop you into the python debugger
>>> . type 'print row'
>>> and you should see what the problem is. If not type 'next' and step
>>> though the code.
>>>
>>> You can execute arbitrary python from the debugger and once you figure
>>> out the problem, I encourage you to play around with it. Aside from
>>> pedantically explaining to yourself what you think going on, pdb is one of
>>> the most generally useful tools.
>>>
>>> On Fri, Apr 24, 2015 at 12:01 AM, sum abiut  wrote:
>>>
 Hi,
 could you please help me figure out why i am getting this error i am
 trying to import data from csv file to model buty i am getting the error: 
 *list
 index out of range* and if refering to line 20 on view which is:
 *data.FirstName=row[1]*

 view.py
 def readcsvfile(request):
 with open('/var/www/html/webapp/csvupload/data.csv','rb') as
 csvfile:
 readata=csv.reader(csvfile,delimiter=';', quotechar='|')
 #readata=csv.reader(csvfile)
 for row in readata:
 data=test()
 data.PersonID=row[0],
 data.FirstName=row[1],
 data.LastName=row[2],
 data.Address=row[3],
 data.save()
 return render_to_response('csv_test.html',locals())



 model.py

 class test(models.Model):
  

Re: Concept of partial views to be resolved from other views or template tags

[Javier Guerra Giraldez]

On Sat, Apr 25, 2015 at 3:11 AM, Stephan Herzog  wrote:
> I like that approach because it leads to any partial being a separated piece
> of logic that can be tested and developed on a dedicated url. If necessary
> it can be wrapped in a templatetag, which makes it easy to use from the
> template layer.


you might be interested in ESI (edge side includes, (partially)
implemented by Varnish [1]) or SSI (Serve Side Includes, as done by
Nginx [2]).  they allow you to describe the 'assembly' of HTML in the
front end, using several fragments retrieved from the backside server
(Django), each one cached independently.

not only you get modularity of code and testability as you describe,
but also avoid the overhead of assembling everything in Python.  you
get more URLs and each request could potentially multiply by a sizable
factor, but you get to easily cache complex pieces that stay constant
even if other parts are more variable, or constant on a different
variable...


[1]: https://www.varnish-cache.org/docs/3.0/tutorial/esi.html
[2]: http://nginx.org/en/docs/http/ngx_http_ssi_module.html

-- 
Javier

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

Internal Server Error os:win8.1 django1.8+apache2.4.12(win64)vc10+wsgi4.4.11+python3.4.3

[gnuhurd92]

[Sat Apr 25 17:07:18.811184 2015] [mpm_winnt:notice] [pid 2456:tid 532] 
AH00455: Apache/2.4.12 (Win64) PHP/5.6.8 mod_wsgi/4.4.11 Python/3.4.3 
configured -- resuming normal operations
[Sat Apr 25 17:07:18.811184 2015] [mpm_winnt:notice] [pid 2456:tid 532] 
AH00456: Apache Lounge VC10 Server built: Jan 29 2015 12:56:33
[Sat Apr 25 17:07:18.811184 2015] [core:notice] [pid 2456:tid 532] AH00094: 
Command line: 'C:\\web-server\\server\\Apache24\\bin\\httpd.exe -d 
C:/web-server/server/Apache24'
[Sat Apr 25 17:07:18.812184 2015] [mpm_winnt:notice] [pid 2456:tid 532] 
AH00418: Parent: Created child process 4212
[Sat Apr 25 17:07:19.258209 2015] [mpm_winnt:notice] [pid 4212:tid 524] 
AH00354: Child: Starting 64 worker threads.
[Sat Apr 25 17:07:34.922102 2015] [wsgi:error] [pid 4212:tid 1060] Internal 
Server Error: /\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
Traceback (most recent call last):\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\core\\urlresolvers.py", line 
394, in urlconf_module\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
return self._urlconf_module\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
AttributeError: 'RegexURLResolver' object has no attribute 
'_urlconf_module'\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] \r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] During 
handling of the above exception, another exception occurred:\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] \r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
Traceback (most recent call last):\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\core\\handlers\\base.py", line 
119, in get_response\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
resolver_match = resolver.resolve(request.path_info)\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\core\\urlresolvers.py", line 
366, in resolve\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] for 
pattern in self.url_patterns:\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\core\\urlresolvers.py", line 
402, in url_patterns\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
patterns = getattr(self.urlconf_module, "urlpatterns", 
self.urlconf_module)\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\core\\urlresolvers.py", line 
396, in urlconf_module\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
self._urlconf_module = import_module(self.urlconf_name)\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\importlib\\__init__.py", line 109, in import_module\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
return _bootstrap._gcd_import(name[level:], package, level)\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 2254, in _gcd_import\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 2237, in _find_and_load\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 2226, in _find_and_load_unlocked\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 1200, in _load_unlocked\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 1129, in _exec\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 1471, in exec_module\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"", line 321, in _call_with_frames_removed\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\web-server\\server\\www\\gnsinap\\gnsinap\\urls.py", line 9, in 
\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
url(r'^admin/', include(admin.site.urls)),\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\contrib\\admin\\sites.py", line 
291, in urls\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
return self.get_urls(), 'admin', self.name\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\contrib\\admin\\sites.py", line 
250, in get_urls\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060] 
self.check_dependencies()\r
[Sat Apr 25 17:07:34.923102 2015] [wsgi:error] [pid 4212:tid 1060]   File 
"C:\\Python34\\lib\\site-packages\\django\\contrib\\admin\\sites.py", line 
171, in check_dependencies\r
[Sat A

Re: Migrations During Development

[Mike Dewhirst]

On 25/04/2015 10:26 PM, Timothy W. Cook wrote:

Django 1.8 Â Python 3.4 PostgreSQL 9.3

During development I am creating several migrations. It seems
unnecessary to keep these since they only exist on my dev machine. Â
Any data that I have created can be thrown away too.

Is it safe to delete these migrations  (and the database) before
deploying to the next stage for testing by users?Â


If the data can be thrown away I would have no hesitation in dropping 
the entire database, deleting migrations and starting again.


There will come a point when you need to create a database for the users 
to enter their data. From that moment, your dev database and the 
production database must be kept in sync. That is when migrations must 
change your dev database and be stored in your repo to be applied 
against the production database each time you deploy updates to production.


I'm still learning about migrations but I can't see anything wrong with 
answering yes to your question.


mike



--


Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIMÂ http://www.mlhim.org 

--
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%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%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/553B9121.8000208%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations During Development

[Jorge Andrés Vergara Ebratt]

Are you using version control like GIT? I save the migration folder with
the __init__.py in GIT, nothing else, because al the migrations will be
diferent in the diferent servers.

On Sat, Apr 25, 2015, 7:45 AM Filipe Ximenes 
wrote:

> You should keep all project migrations, they will be used to update the
> database everytime a change is made. This applies to your local project,
> the staging server (if you have one) and your production server.
> If you are worried about having to many migrations, you can delete the
> ones that were not applied in other machines, and generate a single one
> with all the changes.
>
> About the database, it can be deleted, but you don't need to do this, your
> database data should only exist in your computer and not in the Django
> project you are deploying.
>
> On Sat, Apr 25, 2015 at 9:26 AM, Timothy W. Cook  wrote:
>
>> Django 1.8  Python 3.4 PostgreSQL 9.3
>>
>> During development I am creating several migrations. It seems unnecessary
>> to keep these since they only exist on my dev machine.
>> Any data that I have created can be thrown away too.
>>
>> Is it safe to delete these migrations  (and the database) before
>> deploying to the next stage for testing by users?
>>
>>
>> --
>>
>> 
>> Timothy Cook
>> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
>> MLHIM http://www.mlhim.org
>>
>>  --
>> 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%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
>
> *Filipe Ximenes*+55 (81) 8245-9204
>
> *Vinta Software Studio*http://www.vinta.com.br
>
> --
> 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/CAA-QWB2RW_39b-8nm0Jm%2BAg9%2Bc%3DV0F4%3Dnm%3D%2B3DM7U-f3njV%3DNw%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/CAAeX05H23hsbciqm%3DXn-PgcGpsA-ezL2Pnx4joP6rWJ%2Bkeirgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations During Development

[Filipe Ximenes]

You should keep all project migrations, they will be used to update the
database everytime a change is made. This applies to your local project,
the staging server (if you have one) and your production server.
If you are worried about having to many migrations, you can delete the ones
that were not applied in other machines, and generate a single one with all
the changes.

About the database, it can be deleted, but you don't need to do this, your
database data should only exist in your computer and not in the Django
project you are deploying.

On Sat, Apr 25, 2015 at 9:26 AM, Timothy W. Cook  wrote:

> Django 1.8  Python 3.4 PostgreSQL 9.3
>
> During development I am creating several migrations. It seems unnecessary
> to keep these since they only exist on my dev machine.
> Any data that I have created can be thrown away too.
>
> Is it safe to delete these migrations  (and the database) before deploying
> to the next stage for testing by users?
>
>
> --
>
> 
> Timothy Cook
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> MLHIM http://www.mlhim.org
>
>  --
> 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%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 


*Filipe Ximenes*+55 (81) 8245-9204

*Vinta Software Studio*http://www.vinta.com.br

-- 
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/CAA-QWB2RW_39b-8nm0Jm%2BAg9%2Bc%3DV0F4%3Dnm%3D%2B3DM7U-f3njV%3DNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: importing csv data into database

[sum abiut]

Ok , i manage to figure out where the error was coming from in my view.py
on line  readata=csv.reader(csvfile,delimiter=';', quotechar='|'). The*
delimiter =';'* i change the semicolon to  a comma The* delimiter =','* and
it works.

However when the data are imported from the csv file to the model it also
write some funny character to the model as shown on the image below. How to
import data to model without writing this funny characters?  i want the
data to be clean


[image: Inline image 1]



view.py
def readcsvfile(request):
with open('/var/www/html/webapp/csvupload/data.csv','rb') as csvfile:
readata=csv.reader(csvfile,delimiter=';', quotechar='|')
#readata=csv.reader(csvfile)
for row in readata:
data=test()
data.PersonID=row[0],
data.FirstName=row[1],
data.LastName=row[2],
data.Address=row[3],
data.save()
return render_to_response('csv_test.html',locals())




On Fri, Apr 24, 2015 at 4:36 PM, Andrew Farrell 
wrote:

> You might have to make sure that my indentation there is correct.
>
> Also, I noticed something else about your code: you are assigning 2-tuples
> to all of your data types rather than strings when you do
>data.PersonID=row[0],
>data.FirstName=row[1],
>data.LastName=row[2],
>data.Address=row[3],
>
> You might actually be aware of this, but I once spent 4 hours debugging
> before I realized this on a previous project.
> weapons = ('fear', 'surprise', 'fanatical devotion to the pope',)
> clearly creates a 3-item tuple. But so does
> weapons = 'fear', 'surprise', 'fanatical devotion to the pope',
> and in fact
> weapons = 'fear',
> creates a 1-item tuple.
>
> On Fri, Apr 24, 2015 at 12:33 AM, Andrew Farrell 
> wrote:
>
>> could you replace your function with
>> def readcsvfile(request):
>> with open('/var/www/html/webapp/csvupload/data.csv','rb') as csvfile:
>> readata=csv.reader(csvfile,delimiter=';', quotechar='|')
>> #readata=csv.reader(csvfile)
>> for i, row in enumerate(readata):
>> try:
>> data=test()
>> data.PersonID=row[0],
>> data.FirstName=row[1],
>> data.LastName=row[2],
>> data.Address=row[3],
>> data.save()
>> except Exception, e:
>> import pdb;pdb.set_trace()
>> print i
>> print row
>> print row[1]
>> raise e
>> return render_to_response('csv_test.html',locals())
>>
>> And then re-run this again? When you hit the offending row of data, it
>> should pop you into the python debugger
>> . type 'print row'
>> and you should see what the problem is. If not type 'next' and step
>> though the code.
>>
>> You can execute arbitrary python from the debugger and once you figure
>> out the problem, I encourage you to play around with it. Aside from
>> pedantically explaining to yourself what you think going on, pdb is one of
>> the most generally useful tools.
>>
>> On Fri, Apr 24, 2015 at 12:01 AM, sum abiut  wrote:
>>
>>> Hi,
>>> could you please help me figure out why i am getting this error i am
>>> trying to import data from csv file to model buty i am getting the error: 
>>> *list
>>> index out of range* and if refering to line 20 on view which is:
>>> *data.FirstName=row[1]*
>>>
>>> view.py
>>> def readcsvfile(request):
>>> with open('/var/www/html/webapp/csvupload/data.csv','rb') as csvfile:
>>> readata=csv.reader(csvfile,delimiter=';', quotechar='|')
>>> #readata=csv.reader(csvfile)
>>> for row in readata:
>>> data=test()
>>> data.PersonID=row[0],
>>> data.FirstName=row[1],
>>> data.LastName=row[2],
>>> data.Address=row[3],
>>> data.save()
>>> return render_to_response('csv_test.html',locals())
>>>
>>>
>>>
>>> model.py
>>>
>>> class test(models.Model):
>>> PersonID = models.CharField(max_length=45)
>>> FirstName = models.CharField(max_length=45)
>>> LastName = models.CharField(max_length=45)
>>> Address = models.CharField(max_length=45)
>>>
>>>
>>> here is the traceback:
>>>
>>>-
>>>
>>> /var/www/html/env/local/lib/python2.7/site-packages/django/core/handlers/base.py
>>>in get_response
>>>response = wrapped_callback(request, *callback_args,
>>>**callback_kwargs
>>>
>>>
>>>/var/www/html/webapp/csvapp/views.py in readcsvfile
>>>data.FirstName=row[1],
>>>
>>>
>>>
>>> Cheers,
>>> Sum
>>>
>>>
>>> On Wed, Apr 1, 2015 at 1:51 PM, sum abiut  wrote:
>>>
 Thanks guys,
 appreciate your help. Yes i am looking to have a form that accepts CSV
 files. I will have a read on the link that you guys have provided and see
 how it goes.

 Cheers

Migrations During Development

[Timothy W. Cook]

Django 1.8  Python 3.4 PostgreSQL 9.3

During development I am creating several migrations. It seems unnecessary
to keep these since they only exist on my dev machine.
Any data that I have created can be thrown away too.

Is it safe to delete these migrations  (and the database) before deploying
to the next stage for testing by users?


-- 


Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
MLHIM http://www.mlhim.org

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

Concept of partial views to be resolved from other views or template tags

[Stephan Herzog]

Hi all,

I am wondering if the following is considered a bad practice and might lead 
to issues. I think it provides a useful pattern, for example for creating 
template tags or simple ajax use cases where the rendered result of a 
partial will get frequently updated.

# partials.py
class SomePartial(View):
""" A view providing partial content. """
def get(self, request):
# related views logic like lookups ...
return render(request, 'patterntests/_partial.html', {})

# views.py
class SomeView(View):
""" Including the partial by calling get on `SomePartial`. """
def get(self, request):
someview = SomePartial()
res = someview.get(request)
ctx = {
'partial_content': mark_safe(res.content)
}
return render(request, 'patterntests/test.html', ctx)


class AnotherView(View):
""" Including the partial by resolving its view. """
def get(self, request):
rev = reverse('patterntests:somepartial')
view, vargs, vkwargs = resolve(rev)
vkwargs['request'] = request
res = view(*vargs, **vkwargs)

ctx = {
'partial_content': mark_safe(res.content)
}

return render(request, 'patterntests/test.html', ctx)

My main question is about the following two lines in SomeView. Does that 
have serious flaws (edge cases, performance, security)?

class SomeView(View):
def get(self, request):
# ...
someview = SomePartial()
res = someview.get(request)
# ...

I like that approach because it leads to any partial being a separated 
piece of logic that can be tested and developed on a dedicated url. If 
necessary it can be wrapped in a templatetag, which makes it easy to use 
from the template layer. On top of that, by implementing something like a 
format='json|html|xml|...' attribute it could be further improved to allow 
for more advanced ajax use cases. However, since I've not seen it being 
used that way I think that this might be for a good reason. (-:

Would appreciate your feedback,

Regards,
Stephan


-- 
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/1fe114be-f037-4318-8da6-49dca4003266%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django restframework based app on heroku showing error HTTP/1.1 505 HTTP Version Not Supported

[Stephen J. Butler]

Your HTTP Request is malformed. You have 2 spaces between the URI and
the HTTP version (rfc says only 1). Also, after your Content-Length
header you have an extra \r\n which will terminate the set of headers
and put the rest in the body.

On Fri, Apr 24, 2015 at 11:50 AM, Anand Singh  wrote:
> I need to send some data from an arduino to an rest based web application.
>
> To test I have created an django based web application on heroku
> http://obttracker.herokuapp.com/api/
>
> Now when I trying to send the data from arduino using GSM AT commands it's
> showing below error
>
> HTTP/1.1 505 HTTP Version Not Supported Connection: close Server: Cowboy
>
> Below is my code in arduino
>
>   const char HTTP_HEADER_POST[ ] = "POST /api/sprints  HTTP/1.1\r\nHost:
> obttracker.herokuapp.com\r\nContent-Length: 54\r\n\r\nUser-Agent:
> obttracker\r\nConnection: keep-alive\r\nContent-Type:
> application/x--form-urlencoded\r\nAuthorization: Basic
> ZGVtbzpkZW1v\r\n\r\n";  //HTTP header line before length
>   const char HTTP_BODY_POST[] =
> "end=2015-05-19&name=TESTING&point=POINT%2834.2+45.3%29";
>
>int tmp_post_len = strlen(HTTP_HEADER_POST);
>//sending header packet to remote host
>gsm_port.print("AT+QISEND=");
>gsm_port.print(tmp_post_len);
>gsm_port.print("\r");
>
>delay(500);
>gsm_get_reply();
>
>//sending header
>gsm_port.print(HTTP_HEADER_POST);
>
>delay(500);
>gsm_get_reply();
>
>//validate header delivery
>gsm_validate_tcp();
>
>// send the body data
>int body_len = strlen(HTTP_BODY_POST);
>gsm_port.print("AT+QISEND=");
>gsm_port.print(body_len);
>gsm_port.print("\r");
>
>delay(500);
>gsm_get_reply();
>
>gsm_port.print(HTTP_BODY_POST);
>
>delay(500);
>gsm_get_reply();
>
>//validate previous transmission
>gsm_validate_tcp();
>
>parse_receive_reply();
>
> I have tested the web app by send through my linux system using python
> requests, and it's working below are the details
>
>$ python
>Python 2.7.3 (default, Mar 13 2014, 11:03:55)
>[GCC 4.7.2] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
>>>> import datetime
>>>> import requests
>>>> import pprint
>>>> today = datetime.date.today()
>>>> data = {'name': 'TESTSTING', 'end': today, 'point': 'POINT(56.3
> 33.3)'}
>>>> resp = requests.get('http://obttracker.herokuapp.com/api')
>>>> resp.status_code
>200
>>>> api = resp.json()
>>>> pprint.pprint(api)
>{u'sprints': u'http://obttracker.herokuapp.com/api/sprints'}
>>>> resp = requests.post(api['sprints'], data=data, auth=('demo',
> 'demo'))
>>>> resp.status_code
>201
>>>> sprint = resp.json()
>>>> pprint.pprint(sprint)
>{u'end': u'2015-04-24',
> u'id': 3,
> u'links': {u'self':
> u'http://obttracker.herokuapp.com/api/sprints/3'},
> u'name': u'TESTSTING',
> u'point': {u'coordinates': [56.3, 33.3], u'type': u'Point'}}
>>>>
>
> Request to please provide me suggestion or help to resolve this issue
>
> --
> 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/4dcc9750-9f45-4bef-9563-169c711f699f%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 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/CAD4ANxWpjLCU58UB9H91So1%2B58DQ%3DAg6E4ctEoA5VDe%2BQmQ-Xg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ModelForm not creating field with required options

[Stephen J. Butler]

You need to set Form.required_css_class

https://docs.djangoproject.com/en/1.8/ref/forms/api/#styling-required-or-erroneous-form-rows

On Fri, Apr 24, 2015 at 2:30 PM, victor menezes
 wrote:
> Hi all,
>
> I'm using Django 1.8 and having trouble to because my form does not generate
> fields with required option even though they have the property "blank=False"
> in the model.
> In the example bellow, shouldn't the field "description" have the "required"
> attribute in the html generated using "form.as_p" or am I missing anything?
>
> models.py
> class Place(models.Model):
> name = models.CharField(max_length=200, blank=False, default='')
> owners = models.ManyToManyField(settings.AUTH_USER_MODEL, blank=False)
> members = models.ManyToManyField(Member, blank=True)
> description =  models.TextField(blank=False)
> location = models.CharField(max_length=400, blank=True)
> additional_info = models.TextField(blank=True)
>
> def __unicode__(self):
> return self.name
>
>
> class PlaceForm(ModelForm):
> class Meta:
> model = Place
> fields = '__all__'
>
> views.py
> @login_required(login_url='/')
> def addPlaceView(request):
> place_form = PlaceForm()
> context = {
> 'form': place_form,
> }
> return render(request, 'newPlace.html', context)
>
> newPlace.html
> 
> {% csrf_token %}
> {{ form.as_p }}
> 
> 
>
> --
> 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/84a2cdf8-f6de-438b-b7d3-775c4300f105%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 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/CAD4ANxU9Ng-2pjkakwM7AZDBgt5McQiv%3D%2Bn75L3SotMsMi5boA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.