Re: Whoosh autocomplete search logging for future analysis

2014-11-08 Thread James Schneider
Wouldn't all of your AJAX requests be logged in your web server access
logs, assuming that you are using GET requests for your searches?  You can
parse those for analysis.

You could also probably configure Whoosh or whatever calls the search
function to write a record in the database with the query, and probably the
results, although probably not advisable on heavily trafficked sites or if
large result sets are common.

-James
On Nov 7, 2014 9:05 AM, "Radek Svarz"  wrote:

> Hi,
>
> what is the best practice to setup the logging of search autocomplete
> logging for future analysis?
>
> When using Whoosh as a search engine and django.
>
> The search is searching within hundred thousands of product names.
>
> We want to get the insight on typos and typical name abbreviations.
>
> The autocomplete searches are performed using AJAX requests to /search/
> URL.
>
> 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+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/b9943bb0-fc6c-4bff-86cc-45f1dd28c1df%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/CA%2Be%2BciVz9VrXfHhPV4S8%3DXUOAm1SVa%3Dfj92JV9CTBNb%3DLCcjGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Whoosh autocomplete search logging for future analysis

2014-11-08 Thread Radek Svarz
Thanks James. In the case of using GET there seams to be plenty of log 
analyzers, so we have a lot of options.

Any best practice / experience when using POST? 

I understand we can store the query to the DB, even using django model for 
that. But I am afraid of the performance hit.

Radek

On Saturday, November 8, 2014 10:42:03 AM UTC+1, James Schneider wrote:
>
> Wouldn't all of your AJAX requests be logged in your web server access 
> logs, assuming that you are using GET requests for your searches?  You can 
> parse those for analysis.
>
> You could also probably configure Whoosh or whatever calls the search 
> function to write a record in the database with the query, and probably the 
> results, although probably not advisable on heavily trafficked sites or if 
> large result sets are common.
>
> -James
> On Nov 7, 2014 9:05 AM, "Radek Svarz" > 
> wrote:
>
>> Hi,
>>
>> what is the best practice to setup the logging of search autocomplete 
>> logging for future analysis? 
>>
>> When using Whoosh as a search engine and django.
>>
>> The search is searching within hundred thousands of product names.
>>
>> We want to get the insight on typos and typical name abbreviations.
>>
>> The autocomplete searches are performed using AJAX requests to /search/ 
>> URL.
>>
>> 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...@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/b9943bb0-fc6c-4bff-86cc-45f1dd28c1df%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/ec51a70c-c16a-471b-9b18-4915b5227f23%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Useing non-ascii character in django

2014-11-08 Thread Hossein Rashnoo
When i return Persian characters in view.py (same as Arabic characters) i 
got an error , So i add this line to top of view.py:
# encoding=utf-8

And now my Persian word is like this :
�
And when i add 'u' before my word again i got error,I run django on Linux 
with Apache. Please help me and sorry for my terrible English.  

-- 
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/268b9011-1f1a-4f2f-8569-8c975a5ba11a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


New to group - into

2014-11-08 Thread Niall
Hi Django-users,

Just to introduce myself to this group, I'm Niall and I have been working 
in web development for the last year and a half. I'm pretty new to the 
Django stuff so please excuse my noob questions :)

I do have a lot of experience in GIS so if you have any questions which may 
be of use to GeoDjango please get in touch and I may be able to help or at 
least point you in the right direction.

Thanks,
Niall

-- 
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/9ae7b814-3d98-4963-b089-c75ec018a8b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Useing non-ascii character in django

2014-11-08 Thread Aliane Abdelouahab
in your html you add 


Le samedi 8 novembre 2014 09:19:10 UTC+1, Hossein Rashnoo a écrit :
>
> When i return Persian characters in view.py (same as Arabic characters) i 
> got an error , So i add this line to top of view.py:
> # encoding=utf-8
>
> And now my Persian word is like this :
> �
> And when i add 'u' before my word again i got error,I run django on Linux 
> with Apache. Please help me and sorry for my terrible English.  
>

-- 
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/c38325f0-89a7-4f11-82d8-29180d36b152%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Useing non-ascii character in django

2014-11-08 Thread Aliane Abdelouahab
and dont forget to use an font that is unicode, using CSS3.

Le samedi 8 novembre 2014 16:47:42 UTC+1, Aliane Abdelouahab a écrit :
>
> in your html you add 
>
>
> Le samedi 8 novembre 2014 09:19:10 UTC+1, Hossein Rashnoo a écrit :
>>
>> When i return Persian characters in view.py (same as Arabic characters) i 
>> got an error , So i add this line to top of view.py:
>> # encoding=utf-8
>>
>> And now my Persian word is like this :
>> �
>> And when i add 'u' before my word again i got error,I run django on Linux 
>> with Apache. Please help me and sorry for my terrible English.  
>>
>

-- 
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/a007184d-97bc-41a5-8607-67a55b68ff99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AttributeError | 'Template' object has no attribute 'render'

2014-11-08 Thread Nakaya Mitsuo
It resolved.

I used "Template" in Database.
It was the cause.
It was a simple mistake.


Thank you.


2014年11月5日水曜日 11時25分27秒 UTC+9 Nakaya Mitsuo:
>
> I got AttributeError.
> Exception Value: 'Template' object has no attribute 'render'
>
> How can I fix it?
> Please help me.
>
> --- CODE --
>
> from django.shortcuts import render
> from django.template import Context, Template
>
> class US_AccountManager(models.Manager):
>def update_account(self, auth_user, email):
>us_profile = auth_user.us_profile
>if auth_user.email == email:
>pass
>else:
>try:
>mail_template = Mail_Template.objects.get(position = 'MC')
>context = Context({'site_root':site_root,
>'app_name':app_name})
>message = Template(mail_template.message).render(context)
>subject = mail_template.subject
>send_mail(subject, message, settings.DEFAULT_FROM_EMAIL, 
> [auth_user.email])
>except Mail_Template.DoesNotExist:
>try:
>send_mail_dict = {'site_root':site_root,
>'app_name':app_name}
>subject = 'From' + app_name
>message = 
> render_to_string('txt/change_email.txt',send_mail_dict)
>send_mail(subject, message, 
> settings.DEFAULT_FROM_EMAIL, [auth_user.email])
>except:
>pass
>return auth_user
>
>
> I want to send mail from template ( contain in database ).
> And render the template.
>
> Sorry my poor English.
>

-- 
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/3627d0c9-b046-4e7a-a9c9-6910ed5fd5b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django strange behaviour

2014-11-08 Thread monoBOT
Lists are inmutable You are modifiying the same list everytime you
invoque that view
El 07/11/2014 10:08, "termopro"  escribió:

> I have a view in Django which calls external library/class. The problem is
> that for some reason Django keeps caching results coming from previous
> calls of that class.
>
> Please consider the following simple example:
>
> Django view:
>
> from some_path import Demodef test_view(request):
> demo = Demo()
> result = demo.do_something()
> return render(request, 'test.html',
> { 'result':result }
> )
>
> Demo class:
>
> class Demo():
> result = []
>
> def do_something(self):
> self.result.append(1)
> self.result.append(2)
> self.result.append(3)
> return self.result
>
> You expect result to be [1, 2, 3], right ? WRONG!
>
> The first time a page is loaded you'll get the correct result. But on all
> following requests it will keep incrementing: [1, 2, 3, 1, 2, 3]... [1, 2,
> 3, 1, 2, 3, 1, 2, 3] ...
>
> So my question is obvious - what is going on here ? How do i receive [1,
> 2, 3] every time i call a class inside Django view ?
>
> p.s. - Django 1.7 / MacOSx
>
> --
> 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/72ee993f-cc34-4aee-9455-694b09148d8d%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/CA%2BxOsGBKMHmMWP8MxSo0tU7Fmrob6Z%3DRdvNdWv%3DGxcYF3rX7aA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django strange behaviour

2014-11-08 Thread Aliane Abdelouahab
you are calling the function twice, appending every element, and then 
appending the whole list!


Le samedi 8 novembre 2014 18:07:04 UTC+1, monoBOT monoBOT a écrit :
>
> Lists are inmutable You are modifiying the same list everytime you 
> invoque that view
> El 07/11/2014 10:08, "termopro" > 
> escribió:
>
>> I have a view in Django which calls external library/class. The problem 
>> is that for some reason Django keeps caching results coming from previous 
>> calls of that class.
>>
>> Please consider the following simple example:
>>
>> Django view:
>>
>> from some_path import Demodef test_view(request):
>> demo = Demo()
>> result = demo.do_something()
>> return render(request, 'test.html',
>> { 'result':result }
>> )
>>
>> Demo class:
>>
>> class Demo():
>> result = []
>>
>> def do_something(self):
>> self.result.append(1)
>> self.result.append(2)
>> self.result.append(3)
>> return self.result
>>
>> You expect result to be [1, 2, 3], right ? WRONG!
>>
>> The first time a page is loaded you'll get the correct result. But on all 
>> following requests it will keep incrementing: [1, 2, 3, 1, 2, 3]... [1, 2, 
>> 3, 1, 2, 3, 1, 2, 3] ...
>>
>> So my question is obvious - what is going on here ? How do i receive [1, 
>> 2, 3] every time i call a class inside Django view ?
>>
>> p.s. - Django 1.7 / MacOSx
>>  
>> -- 
>> 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/72ee993f-cc34-4aee-9455-694b09148d8d%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/762d3363-5db5-4e10-8ae1-1b603b11e969%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django strange behaviour

2014-11-08 Thread Aliane Abdelouahab
here is what is gives in the console:

class Demo():
result = []

def do_something(self):
self.result.append(1)
self.result.append(2)
self.result.append(3)
return self.result


demo = Demo()

result = demo.do_something()

result
[1, 2, 3]

demo = Demo()

result = demo.do_something()

demo = Demo()

result
[1, 2, 3, 1, 2, 3]

-- 
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/30476e1b-a2e7-416f-9f34-0017bc87499f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Django strange behaviour

2014-11-08 Thread Rafał Pitoń
This happens because "result" is class level attribute, not instance one, 
and its expected behaviour in Python.

To made result instance attribute, define it in your __init__:

class Demo():

def __init__(self):
self.result = []

def do_something(self):
self.result.append(1)
self.result.append(2)
self.result.append(3)
return self.result


-- 
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/80ad2ab0-aa87-46ac-8ad6-cc60ce33fe34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Integrate Google Cloud Sql.

2014-11-08 Thread Aliane Abdelouahab
what you change (since it is just a mysql) is the host ip!

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'db_name',
'USER': 'db_name',
'PASSWORD': 'db_password',
'HOST': 'serverIPAddress', 
'PORT': '3306', 
}
}

Le vendredi 7 novembre 2014 07:29:46 UTC+1, Daljit Singh a écrit :
>
> Hello, 
>
> Greetings ..!!
>
> I need to integrate Google Cloud Sql to my django app. Can anybody light 
> me a right way.
>
> *Thanks and Regards:*
> *Daljit Singh.*
> *daljit...@esferasoft.com *
>

-- 
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/c4a14f34-5ece-431d-a353-0bf46c07dc58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Whoosh autocomplete search logging for future analysis

2014-11-08 Thread James Schneider
You generally would store the necessary information as part of your view,
or more likely as part of the form, inside the database for later
retrieval.

In your scenario though, your AJAX requests should be using GET or HEAD
requests, and even the search form itself should be using a GET action,
allowing links to saved searches, but more importantly, capturing the
submitted search terms directly in to your logs (although this may require
some minor tweaking on your web server to log the extra GET parameters upon
the actual form submission).

TL;DR;

Unless you plan on storing the results of the search queries, everything
you need would be in your web server access logs with no changes to Django
itself.

-James
On Nov 8, 2014 5:08 AM, "Radek Svarz"  wrote:

> Thanks James. In the case of using GET there seams to be plenty of log
> analyzers, so we have a lot of options.
>
> Any best practice / experience when using POST?
>
> I understand we can store the query to the DB, even using django model for
> that. But I am afraid of the performance hit.
>
> Radek
>
> On Saturday, November 8, 2014 10:42:03 AM UTC+1, James Schneider wrote:
>>
>> Wouldn't all of your AJAX requests be logged in your web server access
>> logs, assuming that you are using GET requests for your searches?  You can
>> parse those for analysis.
>>
>> You could also probably configure Whoosh or whatever calls the search
>> function to write a record in the database with the query, and probably the
>> results, although probably not advisable on heavily trafficked sites or if
>> large result sets are common.
>>
>> -James
>> On Nov 7, 2014 9:05 AM, "Radek Svarz"  wrote:
>>
>>> Hi,
>>>
>>> what is the best practice to setup the logging of search autocomplete
>>> logging for future analysis?
>>>
>>> When using Whoosh as a search engine and django.
>>>
>>> The search is searching within hundred thousands of product names.
>>>
>>> We want to get the insight on typos and typical name abbreviations.
>>>
>>> The autocomplete searches are performed using AJAX requests to /search/
>>> URL.
>>>
>>> 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...@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/b9943bb0-fc6c-4bff-86cc-45f1dd28c1df%
>>> 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/ec51a70c-c16a-471b-9b18-4915b5227f23%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/CA%2Be%2BciVaD%3DL44-5iH8wjETN5mUCPFZM8Fj0_vJV2cb%3DWHJexSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


createsuperuser tells me its been skipped due to not running in a tty and then tells me i can do it manually by running createsuperuser. Very confused

2014-11-08 Thread Andri Sigurðsson
Ok i'm running this on a cygwin zsh shell.

with python 3.4.1 and Django 1.7.1

I've been running the first app Tutorial on the Django site and its all 
been going perfectly right up to this moment and i'm absolutely stumped.

When i try to run "./manage.py createsuperuser"  it gives me this error.

"Superuser creation skipped due to not running in a TTY. You can run 
`manage.py createsuperuser` in your project to create one manually."

I havn't been able to find any posts on this particular issue,  any ideas? 
:(

-- 
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/448a6acf-6497-4708-9f28-26d7abad043e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: createsuperuser tells me its been skipped due to not running in a tty and then tells me i can do it manually by running createsuperuser. Very confused

2014-11-08 Thread James Schneider
While I haven't tried running management commands in a shell other than
bash, it's possible that the commands are relying on environment variables
that may not be accessible or set/available in zsh. Trying running them in
bash or sh if available.

If you are running them directly via one-time SSH commands (ie $ ssh host
'command'),  note that SSH does not request a full TTY and runs everything
inside of a channel, which may also pose problems.

-James
On Nov 8, 2014 2:47 PM, "Andri Sigurðsson"  wrote:

> Ok i'm running this on a cygwin zsh shell.
>
> with python 3.4.1 and Django 1.7.1
>
> I've been running the first app Tutorial on the Django site and its all
> been going perfectly right up to this moment and i'm absolutely stumped.
>
> When i try to run "./manage.py createsuperuser"  it gives me this error.
>
> "Superuser creation skipped due to not running in a TTY. You can run
> `manage.py createsuperuser` in your project to create one manually."
>
> I havn't been able to find any posts on this particular issue,  any ideas?
> :(
>
>  --
> 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/448a6acf-6497-4708-9f28-26d7abad043e%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/CA%2Be%2BciXdEatKM2MgY11OC57TS%3Do8Am4SrfGrdtomj191%3DGsg3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: New to group - into

2014-11-08 Thread Russell Keith-Magee
Hi Niall,

On Sat, Nov 8, 2014 at 3:39 PM, Niall  wrote:

> Hi Django-users,
>
> Just to introduce myself to this group, I'm Niall and I have been working
> in web development for the last year and a half. I'm pretty new to the
> Django stuff so please excuse my noob questions :)
>

Welcome to the group!

I do have a lot of experience in GIS so if you have any questions which may
> be of use to GeoDjango please get in touch and I may be able to help or at
> least point you in the right direction.
>

Be careful what you offer - we might just take you up on it :-)

We're always on the lookout for people with GIS experience to help maintain
GeoDjango - I can't say I can point you at a specific hit list, but any
tickets in Django's Trac instance that are flagged against the contrib.gis
module:

https://code.djangoproject.com/query?status=assigned&status=new&component=GIS&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id

would be a good place to start.

Yours,
Russ Magee %-)

-- 
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_wt%2BR7At8tgCg-q4%2BvUQ_K6ve-_LTQNuwGL-3bS71r3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: A migration in one app that adds a field to another

2014-11-08 Thread jMyles Holmes
In case anybody was following this discussion:

I have written a blog post about my conclusions here:
https://kayemyles.com/blog/using-django-17s-migrations-framework-with-mezzanine/

...and opened an Issue in Mezzanine to address the situation here:
https://github.com/stephenmcd/mezzanine/issues/1150

On Tue, Nov 4, 2014 at 4:54 PM, Justin Myles Holmes
 wrote:
> Carl:
>
> Actually, the "subclass the operation" method fails for obvious reasons
> here:
>
> https://github.com/django/django/blob/df0523debcc2d0984f1bc11d323f04227d4b388b/django/apps/registry.py#L202
>
> I'm increasingly thinking that using MIGRATION_MODULES and just maintaining
> a local copy of Mezzanine's migration is the simplest solution.  I sense
> that I'm going to face some resistance if I suggest changing their docs to
> reflect this.  I'll start with a blog post.
>
>
>
> On 11/04/2014 04:30 PM, Justin Myles Holmes wrote:
>
> Well, as I say, I don't particularly like this field injection notion, and
> I'm happy to individually subclass where needed in my own projects.
>
> I'm less surefooted about issuing a pull request to mezzanine to alter their
> docs to suggest doing this, although the doc is currently ambiguous enough
> to be of little use anyway.
>
> I think that you and Carl have changed my mind about the reasonableness of
> including migrations in one app for a model in another.  I'm no longer able
> to think of a scenario that justifies it.
>
>
> On 11/04/2014 04:12 PM, Andrew Godwin wrote:
>
> Carl is right that this isn't a supported thing; Django models are designed
> to be static, and not mutate based on settings.
>
> Migrations are designed to only support one linear change history of models;
> swappable models are just about supported but not perfect and leads to
> issues. Adding in the ability to change or remove other fields based on
> installed models is kind of against the way migrations is designed and
> you'll have to do a lot of work to get around it.
>
> In this particular case, it's possible to make it work, but you'll have to
> subclass every one of the actions you want to use and provide a way to
> override the app_label it operates on, and manually construct the migrations
> to get the dependencies correct and non-circular (as I said, you'll have to
> do a lot of work to get around it). As long as you have anything resembling
> magically changing models in your project, you're not going to be able to
> use anything makemigrations outputs and expect it to Just Work™.
>
> Andrew
>
> On Tuesday, November 4, 2014 3:59:23 PM UTC-8, Carl Meyer wrote:
>>
>> Hi Justin,
>>
>> On 11/04/2014 04:42 PM, Justin Myles Holmes wrote:
>> >> I don't understand this use case. A ForeignKey impacts only one
>> >> database
>> > table's schema; the table for the model on which the ForeignKey field is
>> > located. The schema of the model the ForeignKey points to doesn't need
>> > to change at all based on the presence or absence of some other
>> > ForeignKey pointing to it.
>> >
>> > Example:
>> >
>> > Two apps: apps.coconuts and apps.swallows, each with a canonical model
>> > (Coconut and Swallow, respectively).
>> >
>> > The organization runs two version of the project: one with apps.swallows
>> > and one without.
>> >
>> > The one with apps.swallows needs a field on Coconut, "carried," which is
>> > a FK -=> Swallow.
>>
>> This is basically the same use case as the Mezzanine one - it's
>> attempting to make a model more "reusable" by monkeypatching it with
>> additional fields from outside. I think this should be avoided and
>> discouraged, not better supported.
>>
>> The specifics of how to avoid would depend on details of the case, but I
>> would look towards providing the reusable portions of the model as an
>> abstract base, and maybe additionally using swappable models if other
>> models need to have an FK to the "extendable" model.
>>
>> (Swappable models aren't yet formally supported for use outside
>> contrib.auth, and there are still rough edges in migration's support for
>> them, but I think moving them towards formal support is a much better
>> answer to this general use case than monkeypatching fields onto models.)
>>
>> Another possibility (which I still don't like, but is better than
>> monkeypatching) might be to conditionally define the Coconut.carried
>> field, depending on the value of a setting. In that case, the right
>> solution for migrations is to still define the migration that adds the
>> Coconut.carried field in the coconuts app, but make it conditionally a
>> no-op migration based on the value of the same setting.
>>
>> > To me, the proper way to do this is to ship a migration in the swallows
>> > app which adds this field to apps.coconuts.models.Coconut.
>>
>> Sorry, I don't agree that there's anything "proper" about that :-) The
>> migration is a secondary issue here - the basic problem is that you're
>> monkeypatching the Coconut model, and I don't think migrations should
>> support/encourage one app 

Re: New to group - into

2014-11-08 Thread Niall
Thanks  for the welcome Russ, will keep an eye on those posts.  Haha not 
sure how much I  could help out considering it's full on scripting but from 
cartographic/projections/georeferencing side I m sure I could assist you 
lot.

Cheers

Niall


On Sunday, 9 November 2014 10:03:49 UTC+10, Russell Keith-Magee wrote:
>
> Hi Niall,
>
> On Sat, Nov 8, 2014 at 3:39 PM, Niall > 
> wrote:
>
>> Hi Django-users,
>>
>> Just to introduce myself to this group, I'm Niall and I have been working 
>> in web development for the last year and a half. I'm pretty new to the 
>> Django stuff so please excuse my noob questions :)
>>
>  
> Welcome to the group!
>
> I do have a lot of experience in GIS so if you have any questions which 
>> may be of use to GeoDjango please get in touch and I may be able to help or 
>> at least point you in the right direction.
>>
>  
> Be careful what you offer - we might just take you up on it :-) 
>
> We're always on the lookout for people with GIS experience to help 
> maintain GeoDjango - I can't say I can point you at a specific hit list, 
> but any tickets in Django's Trac instance that are flagged against the 
> contrib.gis module:
>
>
> https://code.djangoproject.com/query?status=assigned&status=new&component=GIS&col=id&col=summary&col=status&col=owner&col=type&col=component&col=version&desc=1&order=id
>
> would be a good place to start.
>
> Yours,
> Russ Magee %-)
>
>  
>

-- 
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/1b2d710a-157f-4a39-8bac-09e9965b17b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.