finding intersection of linestring and list of polygon

[tazmainiac]

Hi,

  I'm not sure if this is the right place for this or not - let me know if 
I should post somewhere else (GEOS mailing list).

  I have a large list (1000's) of polygons 
(django.contrib.gis.geos.Polygon), some of which overlap.  What is the most 
efficient way to find which polygons intersect with a LineString?

  I would have thought that turning the list of Polygon's into a 
MultiPolygon, then calling MultiPolygon.intersection with the line segment 
would give me the polygon that the line segment intersected on.  This does 
work, but it just returns the line segment itself.  I'm trying to go the 
other way.

  I was hoping for a faster mechanism than just filter'ing over the 
original polygon list and calling intersect's on it. 

  I'm having to use Django 1.6.7 if that matters.

Thanks,
Taz

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b40ff554-36fe-4a4b-9701-07dc1d1c82a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Multiple Databases --- Migrations

[Luvpreet Singh]

I am using 2 postgres databases in my django app.



 'newpostgre': {
   'ENGINE': 'django.db.backends.postgresql_psycopg2',
   'NAME': 'new_postgre2',
   'USER': 'tester',
   'PASSWORD': 'password',
   'HOST': 'localhost',
   'PORT': '',
   },
   

 'newpostgre2': {
  'ENGINE': 'django.db.backends.postgresql_psycopg2',
  'NAME': 'new_postgre3',
  'USER': 'tester',
  'PASSWORD': 'password',
  'HOST': 'localhost',
  'PORT': '',
 },


I have a very simple model

 

 class Check1(models.Model):
  title = models.CharField(max_length=100)


I had run

 

python manage.py migrate --database=newpostgre
python manage.py migrate --database=newpostgre2


when I open my new_postgre2(for newpostgre) database in postgre, I can see 
my Check1 table there.


But in my new_postgre3(for newpostgre2) database in postgre, no Check1 
table is there, only those initial migrations are there.


Why I can't see my table in new_postgre3 when migrations have been 
successfully made? Or is there any rule that model can be migrated to only 
1 database ?

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8634-5cba-45a5-b4ef-aa446a0328c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Connecting to a database with logged in user credentials

[konrad . perzyna]

Thank you Melvyn. For now it's the best option we've found.


W dniu czwartek, 23 lutego 2017 18:38:14 UTC+1 użytkownik Melvyn Sopacua 
napisał:
>
> Hi Konrad, 
>
> On Thursday 23 February 2017 02:54:22 konrad@uni.lodz.pl  
> wrote: 
>
>
> > After starting the project, we've realised that db routing is limited 
> > to the set of db connections that are statically described in django 
> > settings. 
>
> Just a few minutes before your post, a link was posted: 
> https://github.com/ambitioninc/django-dynamic-db-router 
>
> So no, they're not static. This package may not suit your needs, but 
> it's mechanism with a custom router should help you along. 
>
> -- 
> Melvyn Sopacua 
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fcd96dc2-5fbf-41f0-8d92-b35cf4626132%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[marcin . j . nowak]

Wanna read something interesting? Look at 
http://t-code.pl/blog/2016/02/rest-misconceptions-0/
You will realize how many "antipatterns" are propagated in turorials on our 
World Wide Web, and where they're already implemented.
 

On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>
> Marcin, that's exactly where I'm stuck! I know endpoints should never be 
> 1:1 serialization of models, but I just don't know how to do that. I mean, 
> I've been able to create endpoints like "/customers/1/payments/" where I 
> use model relationships to generate JSON structures where Customer contains 
> a Payments array field. My Address endpoint seems to be an oddity, as API 
> consumers don't expect the city to contain state and the state to contain 
> country as a JSON structure. How can I add these to the top-level Address 
> entity directly while serialization? That's where I have no answers. Would 
> it be possible for you to point me towards some article that does that? 
> Thanks in advance!
>
> Regards,
> Ankush
>
> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com 
> wrote:
>>
>>
>>
>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>>
>>> If the relationship chain was even deeper, there would be even more 
>>> nesting, which I feel isn't great for API consumers. What is the best 
>>> practice here to put state and country at the same level as the city? 
>>>
>>
>> Just follow REST design. 
>> Forget django models, think about encapsulation.
>> Think about representation of a resource, not about serializing a 
>> model(s).
>> Make semantic representations, as good as possible.
>>
>> You are not forced to do any nested nasty things. This has nothing to do 
>> with REST api.
>> You may feel that DRF is limiting you. You'll be on a good path, if so. :)
>>
>> Good luck!
>> Marcin
>>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1fe8f663-8d38-41af-87e8-8a06bf2301d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[marcin . j . nowak]

On Monday, February 27, 2017 at 3:38:34 PM UTC+1, Xavier Ordoquy wrote:
>
>
> The more strict RESTfull way would be to use the several entry points and 
> use hyperlinks on them (though it would add some extra requests).
>
>
This is just about representation. Nobody forces you to do such things. 
You may include more or less data, require linking or not - it does not 
matter. Client should just *know* what to do - read *something* or *follow 
link* to read *something*. 
Everything is about semantic, not about a structure.

The most important is hyperlinking, hypermedia and the state transfer. 

Marcin

>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/374d2df8-23b1-4bd8-9a22-9203d007d7b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[marcin . j . nowak]

On Monday, February 27, 2017 at 3:30:11 PM UTC+1, Ankush Thakur wrote:
>
> I guess this is the library in question: 
> https://github.com/marcinn/restosaur (took some effort to find it!). 
> Thanks, if I decide to stick with the API-first approach, I'll use it. 
> Either way, I've bookmarked it for future use. :-)
>
>
Yes. I'm not annoucing it, because of entering early beta stage. But on the 
other side I've decided to use it in production starting from early alphas, 
and it just works.
This is a thin glue between web framework and your REST(-ful, -ish, plain 
http, what you want) services, so there is no big issues at all.
Last commits gave me possibility to run api top on a Flask framework, so it 
is fun. 
Still alpha-beta, so I can't give you any guarantee of satisfaction ;)

DRF has mature community, support, etc. Use it if it will work for you. 
Otherwise you're welcome to Restosaur community. 

BR,
Marcin

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3d957a6d-da43-4f48-80d6-cd82f22a7817%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[Xavier Ordoquy]

Quick question. How will you handle the fields updates ?
Like, what if you get an city_name="Bombay" and city_code="DEL" ?

If you can set them as read-only, then using the source argument is the way 
to go.
Alternatively, you can define a non model serializer and flatten the data 
before hand.
You can also decide to drop the serializers and pass a Python structure 
directly though you would have some work for the validation.

The more strict RESTfull way would be to use the several entry points and 
use hyperlinks on them (though it would add some extra requests).

You have a couple of options opened to you.
Remember that Django REST framework is no silver bullet.
You should think about how you want to represent your resources first and 
then write the associated code.
Also remember that easy isn't the same as simple. The framework targets the 
latter.

Regards,
Xavier.

Le mardi 21 février 2017 20:13:25 UTC+1, Ankush Thakur a écrit :
>
> I'm using DRF for an API. My problem is that I defined my postal address 
> like this (breaking it up into City, State, Country):
>
> class Country(models.Model):
> class Meta:
> db_table = 'countries'
>
> name = models.TextField()
> code = models.TextField(unique=True)
>
> class State(models.Model):
> class Meta:
> db_table = 'states'
>
> name = models.TextField()
> code = models.TextField(unique=True)
> country = models.ForeignKey('Country', on_delete=models.CASCADE)
>
>
> class City(models.Model):
> class Meta:
> db_table = 'cities'
>
> name = models.TextField()
> code = models.TextField(unique=True)
> state = models.ForeignKey('State', on_delete=models.CASCADE)
>
> class Address(models.Model):
> class Meta:
> db_table = 'addresses'
> 
> building_no = models.TextField()
> street = models.TextField(null=True)
> locality = models.TextField(null=True)
> landmark = models.TextField(null=True)
> pincode = models.TextField(null=True)
> latitude = models.DecimalField(max_digits=9, decimal_places=6, 
> null=True)
> longitude = models.DecimalField(max_digits=9, decimal_places=6, 
> null=True)
> city = models.ForeignKey('City', on_delete=models.CASCADE)
>
> Now, in my system, a venue has an address, and so the serializes are 
> defined like this:
>
> class VenueSerializer(serializers.ModelSerializer):
> address = AddressSerializer()
> offerings = OfferingSerializer(many=True)
>
> class Meta:
> model = Venue
> fields = ['id', 'name', 'price_per_day', 'status', 'offerings', 
> 'address', 'photos']
>
> which leads us to:
>
> class AddressSerializer(serializers.ModelSerializer):
> city = CitySerializer()
>
> class Meta:
> model = Address
> fields = ['id', 'building_no', 'street', 'locality', 'landmark', 
> 'pincode', 'latitude', 'longitude', 'city']
>
> which leads us to:
>
> class CitySerializer(serializers.ModelSerializer):
> state = StateSerializer()
>
> class Meta:
> model = City
> fields = ['id', 'name', 'code', 'state']
>
> which leads us to:
>
> class StateSerializer(serializers.ModelSerializer):
> country = CountrySerializer()
>
> class Meta:
> model = State
> fields = ['id', 'name', 'code', 'country']
>
> which finally leads to:
>
> class CountrySerializer(serializers.ModelSerializer):
> class Meta:
> model = Country
> fields = ['id', 'name', 'code']
>
> and when this gets serialized, the address is given in the following 
> format:
>
>  "address": {
>   "id": 2,
>   "building_no": "11",
>   "street": "Another Street",
>   "locality": "",
>   "landmark": "Fortis Hospital",
>   "pincode": "201003",
>   "latitude": "28.632778",
>   "longitude": "77.219722",
>   "city": {
> "id": 1,
> "name": "Delhi",
> "code": "DEL",
> "state": {
>   "id": 1,
>   "name": "Delhi",
>   "code": "DEL",
>   "country": {
> "id": 1,
> "name": "India",
> "code": "IN"
>   }
> }
>   }
> }
>
> So there's a hell lot of nesting from city to state to country. If the 
> relationship chain was even deeper, there would be even more nesting, which 
> I feel isn't great for API consumers. What is the best practice here to put 
> state and country at the same level as the city? I think this will also 
> complicate the logic while POSTing data, so I'm interested in knowing about 
> that as well.
>
> I'm sorry if there is too much code, but I couldn't think of a better way 
> to convey the situation than actually post everything.
>
>
> Regards,
> Ankush Thakur
>

-- 
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, 

Re: Flattening model relationships (in APIs)

[Ankush Thakur]

I guess this is the library in question:
https://github.com/marcinn/restosaur (took some effort to find it!).
Thanks, if I decide to stick with the API-first approach, I'll use it.
Either way, I've bookmarked it for future use. :-)


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:53 PM,  wrote:

> I was limited by DRF long days ago and I realized that it is not following
> REST architecutre. It does good job in automation in exposing models over
> http, but everything else is way complicated.
> But there were no problem mix both tools in one project. DRF was for "80%"
> of work and my lib for the rest. Downsides? Two libs used to get the job
> done.
>
> Maybe try using DRF's @api_view decorator for function views, and return a
> pure and manually "flattened" dict?
>
> M.
>
>
> On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote:
>>
>> Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm
>> myself finding DRF too restrictive once you are past the effort-saving
>> magic. Thank you. I might give it up as it's still early days in the
>> project.
>>
>>
>> Regards,
>> Ankush Thakur
>>
>> On Mon, Feb 27, 2017 at 7:43 PM,  wrote:
>>
>>> I'm not sure you want to read my answer, really...  I've finally stopped
>>> using DRF and wrote own library which is focused on resources, linking and
>>> representations.
>>> I think you can do some customization in DRF, probably you ca declare
>>> custom serializer class, but this is a hard way, IMO.
>>>
>>> I like simple things, so with my lib I can just do something like that:
>>>
>>> payments = api.resource('/payments/')
>>> customer = api.resource('/customers/:pk')
>>>
>>>
>>> @payments.representation
>>> def payment_as_json(payment, ctx):
>>> return {
>>> 'customer_address': payment.customer.address,
>>> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), #
>>> link resources
>>> 'value': payment.value,  # write here
>>> 'and_so_on': True,  # what do you want
>>> }
>>>
>>> Yes, it does not validate automatically and this example is not restful,
>>> but you may follow semantic structures like jsonld without any limitation,
>>> and apply validation in a controller:
>>>
>>> @payments.post(accept='application/json')
>>> def add_payment(ctx):
>>> form = PaymentForm(data=ctx.body)
>>> form.is_valid() and form.save(0
>>> [...]
>>>
>>> Where PaymentForm may be a typical Django Form or ModelForm, or even a
>>> Colander Schema.
>>> There is more code to write, but implementation is more explitic.
>>>
>>> PEP20: Explicit is better than implicit. Simple is better than complex.
>>> Flat is better than nested. Readability counts.  And so on...
>>>
>>> BR,
>>> Marcin
>>>
>>>
>>>
>>> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:

 Marcin, that's exactly where I'm stuck! I know endpoints should never
 be 1:1 serialization of models, but I just don't know how to do that. I
 mean, I've been able to create endpoints like "/customers/1/payments/"
 where I use model relationships to generate JSON structures where Customer
 contains a Payments array field. My Address endpoint seems to be an oddity,
 as API consumers don't expect the city to contain state and the state to
 contain country as a JSON structure. How can I add these to the top-level
 Address entity directly while serialization? That's where I have no
 answers. Would it be possible for you to point me towards some article that
 does that? Thanks in advance!

 Regards,
 Ankush

 On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30,
 marcin@gmail.com wrote:
>
>
>
> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>
>> If the relationship chain was even deeper, there would be even more
>> nesting, which I feel isn't great for API consumers. What is the best
>> practice here to put state and country at the same level as the city?
>>
>
> Just follow REST design.
> Forget django models, think about encapsulation.
> Think about representation of a resource, not about serializing a
> model(s).
> Make semantic representations, as good as possible.
>
> You are not forced to do any nested nasty things. This has nothing to
> do with REST api.
> You may feel that DRF is limiting you. You'll be on a good path, if
> so. :)
>
> Good luck!
> Marcin
>
 --
>>> 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/to
>>> pic/django-users/ttoJbZJOBnU/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at 

Re: Flattening model relationships (in APIs)

[marcin . j . nowak]

I was limited by DRF long days ago and I realized that it is not following 
REST architecutre. It does good job in automation in exposing models over 
http, but everything else is way complicated.
But there were no problem mix both tools in one project. DRF was for "80%" 
of work and my lib for the rest. Downsides? Two libs used to get the job 
done.

Maybe try using DRF's @api_view decorator for function views, and return a 
pure and manually "flattened" dict?

M.


On Monday, February 27, 2017 at 3:17:35 PM UTC+1, Ankush Thakur wrote:
>
> Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm 
> myself finding DRF too restrictive once you are past the effort-saving 
> magic. Thank you. I might give it up as it's still early days in the 
> project.
>
>
> Regards,
> Ankush Thakur
>
> On Mon, Feb 27, 2017 at 7:43 PM,  
> wrote:
>
>> I'm not sure you want to read my answer, really...  I've finally stopped 
>> using DRF and wrote own library which is focused on resources, linking and 
>> representations.
>> I think you can do some customization in DRF, probably you ca declare 
>> custom serializer class, but this is a hard way, IMO.
>>
>> I like simple things, so with my lib I can just do something like that:
>>
>> payments = api.resource('/payments/')
>> customer = api.resource('/customers/:pk')
>>
>>
>> @payments.representation
>> def payment_as_json(payment, ctx):
>> return {
>> 'customer_address': payment.customer.address,
>> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), # 
>> link resources
>> 'value': payment.value,  # write here
>> 'and_so_on': True,  # what do you want
>> }
>>
>> Yes, it does not validate automatically and this example is not restful, 
>> but you may follow semantic structures like jsonld without any limitation, 
>> and apply validation in a controller:
>>
>> @payments.post(accept='application/json')
>> def add_payment(ctx):
>> form = PaymentForm(data=ctx.body)
>> form.is_valid() and form.save(0
>> [...]
>>
>> Where PaymentForm may be a typical Django Form or ModelForm, or even a 
>> Colander Schema. 
>> There is more code to write, but implementation is more explitic.
>>
>> PEP20: Explicit is better than implicit. Simple is better than complex. 
>> Flat is better than nested. Readability counts.  And so on...
>>
>> BR,
>> Marcin
>>
>>
>>
>> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>>>
>>> Marcin, that's exactly where I'm stuck! I know endpoints should never be 
>>> 1:1 serialization of models, but I just don't know how to do that. I mean, 
>>> I've been able to create endpoints like "/customers/1/payments/" where I 
>>> use model relationships to generate JSON structures where Customer contains 
>>> a Payments array field. My Address endpoint seems to be an oddity, as API 
>>> consumers don't expect the city to contain state and the state to contain 
>>> country as a JSON structure. How can I add these to the top-level Address 
>>> entity directly while serialization? That's where I have no answers. Would 
>>> it be possible for you to point me towards some article that does that? 
>>> Thanks in advance!
>>>
>>> Regards,
>>> Ankush
>>>
>>> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, 
>>> marcin@gmail.com wrote:



 On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>
> If the relationship chain was even deeper, there would be even more 
> nesting, which I feel isn't great for API consumers. What is the best 
> practice here to put state and country at the same level as the city? 
>

 Just follow REST design. 
 Forget django models, think about encapsulation.
 Think about representation of a resource, not about serializing a 
 model(s).
 Make semantic representations, as good as possible.

 You are not forced to do any nested nasty things. This has nothing to 
 do with REST api.
 You may feel that DRF is limiting you. You'll be on a good path, if so. 
 :)

 Good luck!
 Marcin

>>> -- 
>> 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/ttoJbZJOBnU/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>

Re: Flattening model relationships (in APIs)

[Ankush Thakur]

Hmmm. That's not an answer I wanted to hear, really, but I like it. I'm
myself finding DRF too restrictive once you are past the effort-saving
magic. Thank you. I might give it up as it's still early days in the
project.


Regards,
Ankush Thakur

On Mon, Feb 27, 2017 at 7:43 PM,  wrote:

> I'm not sure you want to read my answer, really...  I've finally stopped
> using DRF and wrote own library which is focused on resources, linking and
> representations.
> I think you can do some customization in DRF, probably you ca declare
> custom serializer class, but this is a hard way, IMO.
>
> I like simple things, so with my lib I can just do something like that:
>
> payments = api.resource('/payments/')
> customer = api.resource('/customers/:pk')
>
>
> @payments.representation
> def payment_as_json(payment, ctx):
> return {
> 'customer_address': payment.customer.address,
> 'customer_url': ctx.link_to(customer, pk=payment.customer_id), #
> link resources
> 'value': payment.value,  # write here
> 'and_so_on': True,  # what do you want
> }
>
> Yes, it does not validate automatically and this example is not restful,
> but you may follow semantic structures like jsonld without any limitation,
> and apply validation in a controller:
>
> @payments.post(accept='application/json')
> def add_payment(ctx):
> form = PaymentForm(data=ctx.body)
> form.is_valid() and form.save(0
> [...]
>
> Where PaymentForm may be a typical Django Form or ModelForm, or even a
> Colander Schema.
> There is more code to write, but implementation is more explitic.
>
> PEP20: Explicit is better than implicit. Simple is better than complex.
> Flat is better than nested. Readability counts.  And so on...
>
> BR,
> Marcin
>
>
>
> On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>>
>> Marcin, that's exactly where I'm stuck! I know endpoints should never be
>> 1:1 serialization of models, but I just don't know how to do that. I mean,
>> I've been able to create endpoints like "/customers/1/payments/" where I
>> use model relationships to generate JSON structures where Customer contains
>> a Payments array field. My Address endpoint seems to be an oddity, as API
>> consumers don't expect the city to contain state and the state to contain
>> country as a JSON structure. How can I add these to the top-level Address
>> entity directly while serialization? That's where I have no answers. Would
>> it be possible for you to point me towards some article that does that?
>> Thanks in advance!
>>
>> Regards,
>> Ankush
>>
>> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com
>> wrote:
>>>
>>>
>>>
>>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:

 If the relationship chain was even deeper, there would be even more
 nesting, which I feel isn't great for API consumers. What is the best
 practice here to put state and country at the same level as the city?

>>>
>>> Just follow REST design.
>>> Forget django models, think about encapsulation.
>>> Think about representation of a resource, not about serializing a
>>> model(s).
>>> Make semantic representations, as good as possible.
>>>
>>> You are not forced to do any nested nasty things. This has nothing to do
>>> with REST api.
>>> You may feel that DRF is limiting you. You'll be on a good path, if so.
>>> :)
>>>
>>> Good luck!
>>> Marcin
>>>
>> --
> 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/ttoJbZJOBnU/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALX%3DrK%2BOxWenwEJwFfHeeY8ipVuWo7Uz4YqoNtHNXEYYz-aRZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[marcin . j . nowak]

I'm not sure you want to read my answer, really...  I've finally stopped 
using DRF and wrote own library which is focused on resources, linking and 
representations.
I think you can do some customization in DRF, probably you ca declare 
custom serializer class, but this is a hard way, IMO.

I like simple things, so with my lib I can just do something like that:

payments = api.resource('/payments/')
customer = api.resource('/customers/:pk')


@payments.representation
def payment_as_json(payment, ctx):
return {
'customer_address': payment.customer.address,
'customer_url': ctx.link_to(customer, pk=payment.customer_id), # 
link resources
'value': payment.value,  # write here
'and_so_on': True,  # what do you want
}

Yes, it does not validate automatically and this example is not restful, 
but you may follow semantic structures like jsonld without any limitation, 
and apply validation in a controller:

@payments.post(accept='application/json')
def add_payment(ctx):
form = PaymentForm(data=ctx.body)
form.is_valid() and form.save(0
[...]

Where PaymentForm may be a typical Django Form or ModelForm, or even a 
Colander Schema. 
There is more code to write, but implementation is more explitic.

PEP20: Explicit is better than implicit. Simple is better than complex. 
Flat is better than nested. Readability counts.  And so on...

BR,
Marcin



On Monday, February 27, 2017 at 2:52:46 PM UTC+1, Ankush Thakur wrote:
>
> Marcin, that's exactly where I'm stuck! I know endpoints should never be 
> 1:1 serialization of models, but I just don't know how to do that. I mean, 
> I've been able to create endpoints like "/customers/1/payments/" where I 
> use model relationships to generate JSON structures where Customer contains 
> a Payments array field. My Address endpoint seems to be an oddity, as API 
> consumers don't expect the city to contain state and the state to contain 
> country as a JSON structure. How can I add these to the top-level Address 
> entity directly while serialization? That's where I have no answers. Would 
> it be possible for you to point me towards some article that does that? 
> Thanks in advance!
>
> Regards,
> Ankush
>
> On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com 
> wrote:
>>
>>
>>
>> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>>
>>> If the relationship chain was even deeper, there would be even more 
>>> nesting, which I feel isn't great for API consumers. What is the best 
>>> practice here to put state and country at the same level as the city? 
>>>
>>
>> Just follow REST design. 
>> Forget django models, think about encapsulation.
>> Think about representation of a resource, not about serializing a 
>> model(s).
>> Make semantic representations, as good as possible.
>>
>> You are not forced to do any nested nasty things. This has nothing to do 
>> with REST api.
>> You may feel that DRF is limiting you. You'll be on a good path, if so. :)
>>
>> Good luck!
>> Marcin
>>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a0b23023-8a5c-4257-ad6d-d72639f85925%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Flattening model relationships (in APIs)

[Ankush Thakur]

Marcin, that's exactly where I'm stuck! I know endpoints should never be 
1:1 serialization of models, but I just don't know how to do that. I mean, 
I've been able to create endpoints like "/customers/1/payments/" where I 
use model relationships to generate JSON structures where Customer contains 
a Payments array field. My Address endpoint seems to be an oddity, as API 
consumers don't expect the city to contain state and the state to contain 
country as a JSON structure. How can I add these to the top-level Address 
entity directly while serialization? That's where I have no answers. Would 
it be possible for you to point me towards some article that does that? 
Thanks in advance!

Regards,
Ankush

On Monday, February 27, 2017 at 3:41:49 AM UTC+5:30, marcin@gmail.com 
wrote:
>
>
>
> On Tuesday, February 21, 2017 at 8:13:25 PM UTC+1, Ankush Thakur wrote:
>>
>> If the relationship chain was even deeper, there would be even more 
>> nesting, which I feel isn't great for API consumers. What is the best 
>> practice here to put state and country at the same level as the city? 
>>
>
> Just follow REST design. 
> Forget django models, think about encapsulation.
> Think about representation of a resource, not about serializing a model(s).
> Make semantic representations, as good as possible.
>
> You are not forced to do any nested nasty things. This has nothing to do 
> with REST api.
> You may feel that DRF is limiting you. You'll be on a good path, if so. :)
>
> Good luck!
> Marcin
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/70189b7c-69db-4b3a-9c3e-935121b76ea9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

What's the best way to create a reusable pagination template?

[Frederik Creemers]

The code for rendering pagination controls in my app is the same everywhere:

{% if is_paginated %}


{% if page_obj.has_previous %}
Previous
{% endif %}
{% if page_obj.has_next %}
Previous
{% endif %}


{% endif %}


So I'm wondering whether there's a good w to create the href for the 
previous and next buttons based on the current url. I can't just take the 
current url and append "?page=..." to it, since the url may already have a 
"page" parameter and/or other querystring parameters. On stackoverflow, 
I've seen people create a replace_url_parameter template tag, which 
replaces the given parameter by parsing the url, changing the param, and 
rebuilding the url again. I can do this, but this seems like such a common 
task that I'm surprised I can't find any tools to do this in django itself.

If there's an open source project that offers this, I might be interested, 
but I'm not sure if I want to take on an extra dependency just for 
pagination urls.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4cf546e8-a01b-4cea-8f42-92a5dcb0ba3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Benefit of 'return Foo.objects.all()' in a ListView

[Richard Jackson]

Brilliant, thanks both, I've got it working in both ways!

Much appreciated,

Rich

On Saturday, February 25, 2017 at 2:14:10 PM UTC, Melvyn Sopacua wrote:
>
> Hi Richard,
>
>  
>
> Don't be discouraged to ask questions. It's what the list is for.
>
>  
>
> Ludovic is right, you'd normally use the regroup tag. But let's say you 
> wanted to do this, then get_queryset isn't the right method.
>
> It should return a queryset, and one only.
>
>  
>
> On Saturday 25 February 2017 03:42:11 Richard Jackson wrote:
>
>  
>
> > class MyBlogPosts(generic.ListView):
>
> > def get_queryset(self, request):
>
>  
>
> My bad: request is not an argument here.
>
>  
>
> > ...is it possible to return two uniquely identifiable sets - for
>
> > example, if a model has a function which returns True or False, to
>
> > return one set for all the True and one for all the False?
>
>  
>
> General overview:
>
>  
>
> The goal of a View is to turn a HTTP request into a HTTP response. A 
> Template 
> 
>  
> provides context 
> 
>  
> to the template,
>
> A ListView 
>  
> uses a Template to do that and is responsible for providing a list of 
> ModelInstances 
> 
>  
> to the template. The get_queryset() method is used to retrieve those 
> instances.
>
>  
>
> So, the logical place to provide a different grouping of a queryset is in 
> the part where it gets sent to the template:
>
>  
>
> class BlogRoll(generic.ListView):
>
> def get_context_data(self, **kwargs):
>
> # let ListView do the hard work first
>
> context = super(BlogRoll, self).get_context_data(**kwargs)
>
> # Now make two groups
>
> qs = context['object_list']
>
> group1 = [ obj for obj in qs if obj.boolean_method() is True ]
>
> group2 = [ obj for obj in qs if obj.boolean_method() is False ]
>
> # update the context
>
> context.update(
>
> { 'group1': group1, 'group2': group2 }
>
> )
>
> # and return it
>
> return context
>
>  
>
>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/31f0c37d-d38b-460c-a630-c39ef5c164f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple Databases

[ludovic coues]

Have you checked your settings for typo ?

2017-02-27 10:02 GMT+01:00 Luvpreet Singh :
> But dylan, I have written that
>
> Check1.objects.using('default').all()
>
> gives me error.
>
> On Mon, Feb 27, 2017 at 1:08 PM, Dylan Reinhold  wrote:
>>
>> It is going to use the database named default.
>> Checkout the doc on using mutiple DBs
>> https://docs.djangoproject.com/en/1.10/topics/db/multi-db/
>>
>> Dylan
>>
>>
>> On Sun, Feb 26, 2017 at 11:17 PM, Luvpreet Singh 
>> wrote:
>>>
>>> Hi everyone,
>>>
>>> I am using 2 databases in my django app. One is default sqlite and second
>>> is postgre.
>>>
>>> Now, I make a simple model named Check1 in my app, having only title
>>> attribute.
>>>
>>> class Check1(models.Model):
>>>   title = models.CharField(max_length=100)
>>>
>>> Now, in my shell,
>>>
>>> >> from check.models import Check1
>>> >> a = Check1(title="first")
>>> >> a.save()
>>> >> Check1.objects.all()   --> this gives the queryset returning 'first'
>>>
>>>
>>> My question is, in which database is it saved, means in my default db or
>>> my postgre db ? or in both ?
>>>
>>> >> Check1.objects.using('default').all()--> it gives me error
>>> >> Check1.objects.using('newpostgre').all()  --> it gives me correct
>>> >> queryset.
>>>
>>> How does I know or set that in which db it will be saved ?
>>>
>>> --
>>> 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 https://groups.google.com/group/django-users.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/3c65b2a4-d409-44a6-8ea9-73aa15989eb2%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> 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/5sxIoy0mDcE/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/CAHtg44BO8P5N-AfYvCjPnBn2p_GxRK9HQ_SRiUw8PWgWfKdtfA%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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAL%2BrqijFBegKbKGmSAZgFEFpJWn75hVoCOYxPJi%3DLHFBrNs_FQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 

Cordialement, Coues Ludovic
+336 148 743 42

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEuG%2BTbCb1wTMTYwP4dKu-Ao1Xec5o%2Bk9DAMxsyP2ZRtuEbPZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple Databases

[Luvpreet Singh]

But dylan, I have written that

Check1.objects.using('default').all()

gives me error.

On Mon, Feb 27, 2017 at 1:08 PM, Dylan Reinhold  wrote:

> It is going to use the database named default.
> Checkout the doc on using mutiple DBs
> https://docs.djangoproject.com/en/1.10/topics/db/multi-db/
>
> Dylan
>
>
> On Sun, Feb 26, 2017 at 11:17 PM, Luvpreet Singh 
> wrote:
>
>> Hi everyone,
>>
>> I am using 2 databases in my django app. One is default sqlite and second
>> is postgre.
>>
>> Now, I make a simple model named Check1 in my app, having only title
>> attribute.
>>
>> class Check1(models.Model):
>>   title = models.CharField(max_length=100)
>>
>> Now, in my shell,
>>
>> >> from check.models import Check1
>> >> a = Check1(title="first")
>> >> a.save()
>> >> Check1.objects.all()   --> this gives the queryset returning 'first'
>>
>>
>> My question is, in which database is it saved, means in my default db or
>> my postgre db ? or in both ?
>>
>> >> Check1.objects.using('default').all()--> it gives me error
>> >> Check1.objects.using('newpostgre').all()  --> it gives me correct
>> queryset.
>>
>> How does I know or set that in which db it will be saved ?
>>
>> --
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-users/3c65b2a4-d409-44a6-8ea9-73aa15989eb2%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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/5sxIoy0mDcE/unsubscribe.
> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/CAHtg44BO8P5N-AfYvCjPnBn2p_GxRK9HQ_SRiUw8PWgWfKdtfA%
> 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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAL%2BrqijFBegKbKGmSAZgFEFpJWn75hVoCOYxPJi%3DLHFBrNs_FQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: group by 3 fields

[marcin . j . nowak]

On Monday, February 27, 2017 at 3:52:38 AM UTC+1, larry@gmail.com wrote:
>
> [SQL] That is a language I 
> have worked in for over 20 years, and when I see a querying need that 
> is how I think, and then I see how can I do that with the ORM. 
>

So I shouldn't give advices for you. We have similar experience, I think.

With Django you may play with .aggregate() and .annotate() functions.
You should be able to do grouping you need Just tell a ORM about aggregates 
you want to use, and it will automagically add group by. 

Let's try group by col1, col2:

> from django.db.models import Count
> from django.contrib.auth.models import User

> print User.objects.values('is_staff', 
'is_superuser').annotate(cnt=Count('*')).query
SELECT `auth_user`.`is_staff`, `auth_user`.`is_superuser`, COUNT(*) AS 
`cnt` FROM `auth_user` GROUP BY `auth_user`.`is_staff`, 
`auth_user`.`is_superuser` ORDER BY NULL

You must tell Django that you need some aggregate, and then ask for 
selecting other values explicitely. These columns will be added to a group 
by.
Please note that as a result you will get iterable of dicts instead of 
model instances, which is pretty reasonable.

BR,
Marcin


-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f9645e56-d8e4-42c2-b7da-36ba76bd67e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.