Re: Populating Django app db with JSON data

Hello,

Indeed, the data migration is the best way. Check out
the documentation here:
https://docs.djangoproject.com/en/1.7/ref/migration-operations/#django.db.migrations.operations.RunPython

You write your function that will be called by the RunPython
and will load your JSON.
Migration are ordered, your first migration will create the
tables and the second (your data migration) will load your
JSON.

To create an empty migration:
./manage.py makemigrations <app> --empty

You can rename to a useful descriptive name the migration
file.

Have a good one

On 03/02/2015 08:16 AM, Sandeep Murthy wrote:

Hi

I've tried to get the answer to this question (which is a bit open-ended) on stackoverflow without much success, which
is basically this: what is the recommended approach to populating a pre-existing Django app database table (generated
from a model and which is currently empty) with JSON data?

There seem to be several alternatives given in the Django documentation (Django 1.7 manual) which include (1) fixtures,
(2) SQL scripts, (3) data migrations.  Of these I am a bit confused by the advice in the manual which suggests that (1)
and (2) are only useful for loading initial data.  That's not what I want to do.  The data that the app needs is going to be
persistent and permanent because the app is intended to be a web query tool for a large dataset that is currently in the
form of several JSON files, each containing on average thousands of JSON objects, each object representing an entry
corresponding to a table entry in a relational db.  The data is not going to be re-loaded or change after entry, and there
is no user facility for changing the data.

The table has been created using the makemigrations and migrate tools, but is empty.  I just need to populate the
table with the JSON data.  It seems that I need to write a custom data migration script that will insert the data into the
table via the interpreter, and then I need to run python manage.py migrate.  Is this the case, and if so, are there
are examples that I could use?

Thanks in advance for any suggestions.

SM

--
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+unsubscribe@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/db5919c5-ace4-4556-b90e-aa47baa26552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: i have a question ,whether Django’s cache framework can support transparent proxy deploy mode at isp environment ?

I don't see how they are related, each is on a different layer

The final user will request a page from the ISP, it may get from its own cache (squid) or request from your django server.

Your django server will produce the response, it may get it from its own cache (memcached) or process it

So in case squid decides to respond from its own cache, django will never see the request

On Mon, Mar 2, 2015 at 8:48 AM, 'johnzeng' via Django users <django-users@googlegroups.com> wrote:

Hello All :

i have a question , if possible , hope to get your advisement

whether Django's cache framework can support transparent proxy at isp environment ?

and our goal is Django's cache framework ( middle cache layer ) + Squid ( transparent proxy mode ) at isp environment ?


although i read the detail , but i can't confirm whether Django's cache framework can support transparent proxy deploy mode

https://docs.djangoproject.com/en/1.7/topics/cache/



   Downstream caches¶
   <https://docs.djangoproject.com/en/1.7/topics/cache/#downstream-caches>

So far, this document has focused on caching your /own/ data. But another type of caching is relevant to Web development, too: caching performed by "downstream" caches. These are systems that cache pages for users even before the request reaches your Web site.

Here are a few examples of downstream caches:

 * Your ISP may cache certain pages, so if you requested a page from
   http://example.com/, your ISP would send you the page without having
   to access example.com directly. The maintainers of example.com have
   no knowledge of this caching; the ISP sits between example.com and
   your Web browser, handling all of the caching transparently.
 * Your Django Web site may sit behind a /proxy cache/, such as Squid
   Web Proxy Cache (http://www.squid-cache.org/), that caches pages for
   performance. In this case, each request first would be handled by
   the proxy, and it would be passed to your application only if needed.
 * Your Web browser caches pages, too. If a Web page sends out the
   appropriate headers, your browser will use the local cached copy for
   subsequent requests to that page, without even contacting the Web
   page again to see whether it has changed.

Downstream caching is a nice efficiency boost, but there's a danger to it: Many Web pages' contents differ based on authentication and a host of other variables, and cache systems that blindly save pages based purely on URLs could expose incorrect or sensitive data to subsequent visitors to those pages.

For example, say you operate a Web email system, and the contents of the "inbox" page obviously depend on which user is logged in. If an ISP blindly cached your site, then the first user who logged in through that ISP would have their user-specific inbox page cached for subsequent visitors to the site. That's not cool.

Fortunately, HTTP provides a solution to this problem. A number of HTTP headers exist to instruct downstream caches to differ their cache contents depending on designated variables, and to tell caching mechanisms not to cache particular pages. We'll look at some of these headers in the sections that follow.



--
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+unsubscribe@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/54F407CD.2030403%40yahoo.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+unsubscribe@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/CAFWa6tLjLcixbsx1f4pRBDDUMViodGua0YugHaoezhA%3DVOOvuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Melb Django School Second GO

Sounds great! I wish I was in Melb rather than Adelaide.

On Monday, 2 March 2015 17:57:35 UTC+10:30, MelbDjango School wrote:

Hey Guys,

Melb Django & Common Code is starting its second round of free classes on Django. The classes are going to be held fortnightly starting March 12 from 4-6pm. They will be going through the essentials of Django to advance topics. The course will be given by leading Django Developers in the industry. Please bring a laptop and we'll provide the rest. See you in School!

If you have any questions please contact melbdjan...@acommoncreative.com.

Cheers,

Darren

--
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+unsubscribe@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/c080a033-e5f0-4e29-af54-a1d1ab16bdc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Wysiwyg and images (Summernote or Froala)

Hi Sakis,

I did manage to solve this using froala ( https://github.com/froala/django-froala-editor)with a two step process.

1) First I set up my environment with gunicorn as the application server and nginx serving up /static/* and /media/*

2) When an image is dragged into froala a http request is made to a django view which uploads the image and returns the path of the image in the form {link:'path/to/file.png''} by viewing the console (ctrl+shift+j in chrome)while dragging images into froala I saw that the wrong path was being returned (a leading / was missing) I edited froala's view.py to return the correct path. While I was there I also edited it to save file uploads to the correct location.

On 1 March 2015 at 00:47, Sakis Brouzioutis <sakisbl7@gmail.com> wrote:

Hi Dave,

I encounter the same problem. Did you find any solution?

I really don't know what is going wrong and the image does not appear.

Sakis

Τη Τετάρτη, 4 Φεβρουαρίου 2015 - 12:04:30 π.μ. UTC+2, ο χρήστης David Mutton έγραψε:

Hi,
I've been trying to integrate a WYSIWYG editor into my Django project. I first started with Summernote and I had no issue integrating the it into admin or a form. I followed the instructions on their github and everything works great except image uploading and inserting. The file is uploading (I can see it in the filesystem) but it does not show up in the editor or in the resulting html.

I thought it was just Summernote and so I switched to Froala but I'm getting the exact same behavior. Is there something I'm missing with image upload inside a wysiwyg?


Dave

--
You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/jKvMnVPnMjM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@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/a0eb7cff-6423-4f86-b4ac-fea9604e6604%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+unsubscribe@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/CAAm-pDp0t4VtTez0NxqhjXvZjmkJoru0bnhWTF0JjL-vCwYFYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Populating Django app db with JSON data

Hi

I've tried to get the answer to this question (which is a bit open-ended) on stackoverflow without much success, which
is basically this: what is the recommended approach to populating a pre-existing Django app database table (generated
from a model and which is currently empty) with JSON data?

There seem to be several alternatives given in the Django documentation (Django 1.7 manual) which include (1) fixtures,
(2) SQL scripts, (3) data migrations.  Of these I am a bit confused by the advice in the manual which suggests that (1)
and (2) are only useful for loading initial data.  That's not what I want to do.  The data that the app needs is going to be
persistent and permanent because the app is intended to be a web query tool for a large dataset that is currently in the
form of several JSON files, each containing on average thousands of JSON objects, each object representing an entry
corresponding to a table entry in a relational db.  The data is not going to be re-loaded or change after entry, and there
is no user facility for changing the data.

The table has been created using the makemigrations and migrate tools, but is empty.  I just need to populate the
table with the JSON data.  It seems that I need to write a custom data migration script that will insert the data into the
table via the interpreter, and then I need to run python manage.py migrate.  Is this the case, and if so, are there
are examples that I could use?

Thanks in advance for any suggestions.

SM

--
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+unsubscribe@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/db5919c5-ace4-4556-b90e-aa47baa26552%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

i have a question ,whether Django’s cache framework can support transparent proxy deploy mode at isp environment ?

Hello All :

i have a question , if possible , hope to get your advisement

whether Django's cache framework can support transparent proxy at isp
environment ?

and our goal is Django's cache framework ( middle cache layer ) + Squid
( transparent proxy mode ) at isp environment ?


although i read the detail , but i can't confirm whether Django's cache
framework can support transparent proxy deploy mode

https://docs.djangoproject.com/en/1.7/topics/cache/



Downstream caches¶
<https://docs.djangoproject.com/en/1.7/topics/cache/#downstream-caches>

So far, this document has focused on caching your /own/ data. But
another type of caching is relevant to Web development, too: caching
performed by "downstream" caches. These are systems that cache pages for
users even before the request reaches your Web site.

Here are a few examples of downstream caches:

* Your ISP may cache certain pages, so if you requested a page from
http://example.com/, your ISP would send you the page without having
to access example.com directly. The maintainers of example.com have
no knowledge of this caching; the ISP sits between example.com and
your Web browser, handling all of the caching transparently.
* Your Django Web site may sit behind a /proxy cache/, such as Squid
Web Proxy Cache (http://www.squid-cache.org/), that caches pages for
performance. In this case, each request first would be handled by
the proxy, and it would be passed to your application only if needed.
* Your Web browser caches pages, too. If a Web page sends out the
appropriate headers, your browser will use the local cached copy for
subsequent requests to that page, without even contacting the Web
page again to see whether it has changed.

Downstream caching is a nice efficiency boost, but there's a danger to
it: Many Web pages' contents differ based on authentication and a host
of other variables, and cache systems that blindly save pages based
purely on URLs could expose incorrect or sensitive data to subsequent
visitors to those pages.

For example, say you operate a Web email system, and the contents of the
"inbox" page obviously depend on which user is logged in. If an ISP
blindly cached your site, then the first user who logged in through that
ISP would have their user-specific inbox page cached for subsequent
visitors to the site. That's not cool.

Fortunately, HTTP provides a solution to this problem. A number of HTTP
headers exist to instruct downstream caches to differ their cache
contents depending on designated variables, and to tell caching
mechanisms not to cache particular pages. We'll look at some of these
headers in the sections that follow.



--
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+unsubscribe@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/54F407CD.2030403%40yahoo.com.
For more options, visit https://groups.google.com/d/optout.

django Search page

which is the best way to implement the following::
i will be having a text box and a Add button

Along with a table below it containing headers class AssesmentBuildingDetails(models.Model):

numbuildingid1 = models.CharField(max_length=14,unique=True)

numbuildingid2 = models.CharField(max_length=7,primary_key=True)

previous_year = models.CharField(max_length=4, blank=True)

previous_year_wardname = models.CharField(max_length=100,blank=True, null=True)

previous_doorno1 = models.CharField(max_length=4,blank=True, null=True)

previous_doorno2 = models.CharField(max_length=10,blank=True, null=True)

current_year = models.CharField(max_length=4, blank=True)

current_year_wardname = models.CharField(max_length=100,blank=True, null=True)

current_doorno1 = models.CharField(max_length=10,blank=True, null=True)

current_doorno2 = models.CharField(max_length=10,blank=True, null=True)

buildingusage = models.CharField(max_length=500,blank=True, null=True)

ownernameaddressmal = models.CharField(max_length=500,blank=True, null=True)

ownernameaddresseng = models.CharField(max_length=500,blank=True, null=True)

plintaarea = models.DecimalField(max_digits=7, decimal_places=2,blank=True, null=True)

class Meta:

db_table = 'assesment_building_details'

my logic is to take the numbuildingid2 as input from the text box and when i press enter either on the text field or click the add button it should search through the database
and add the details to the table without refreshing the whole page. and the clear the textfield and focus on it.
 It will give proper error msg if the numbuildingid2 is not found

please help how and which is the best way to implement this...

thanks

--
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+unsubscribe@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/cf179d74-ea55-428f-9dd0-e4ce2297d01b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.