, 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
&g
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.
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 f
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
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 o
ter 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 ne
ic.
>
> 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, tha
, 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 &quo
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
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?
>
Jus
On Wednesday 22 February 2017 00:39:42 Ankush Thakur wrote:
> 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):
...
> So there's a hell lot of nesting from city to state to country. If the
> relationship chain was even
Hey Mike,
Thanks for your thoughts. Perhaps I presented my requirement incorrectly. I
don't at all want to denormalize the database. My point was that because of
the way models are related, I'm ending up with city containing state
containing country. This, I feel, would be a chore for the front
Also, I don't have any need of providing several types of addresses as of
now. For now I'm just sticking with outputting everything when the address
is requested.
~~ Ankush
On Thursday, February 23, 2017 at 9:13:01 PM UTC+5:30, Ankush Thakur wrote:
>
> Hey Mike,
>
> Thanks for your thoughts. Pe
Ankush
I think you might have to provide more than one method for retrieving an
address so applications can request particular subsets. Perhaps a
local-postal address, international-postal address, geo-location,
what-three-words address and of course the full bucket as required.
I think it i
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.Mod
2014-05-26 18:33 GMT-03:00 Daniele Procida :
> I've an application that's been happily running for a few years, that does
> this:
>
> class Person(Model):
># everyone's a Person
>
> class Researcher(Model):
> # a Researcher is Person who publishes research
> person = models.OneToOneFie
I see your point. In this case I'd recommend giving Researcher two foreign
keys, one towards a Student model and one towards a Staff one, then add
some logic to the model to easily check the actual specialization or to
convert it among them. Basically you get a Researcher that "owns" a Student
or a
On Wed, May 28, 2014, Leonardo Giordani wrote:
>I usually solve such issues with Inheritance. I feel comfortable with it
>because it lets me (in your example) to manage both ResearchStudent and
>ResearchStaff independently, while keeping the Researcher parent model
>available to deal with "global
Daniele,
I usually solve such issues with Inheritance. I feel comfortable with it
because it lets me (in your example) to manage both ResearchStudent and
ResearchStaff independently, while keeping the Researcher parent model
available to deal with "global" queries and data interaction.
As always
I've an application that's been happily running for a few years, that does this:
class Person(Model):
# everyone's a Person
class Researcher(Model):
# a Researcher is Person who publishes research
person = models.OneToOneField(Person)
class Publication(Model):
author = models.Fore
On Fri, 2009-01-09 at 04:06 -0800, rabbi wrote:
> Hi Malcolm,
> Filtering out all the Animals that satisfy that constraint is easy...
> even for a noob like me :)
>
> What I want is for that constraint to be enforced as/before the data
> is inserted as I have a few complex (by my standards) relat
Hi Malcolm,
Filtering out all the Animals that satisfy that constraint is easy...
even for a noob like me :)
What I want is for that constraint to be enforced as/before the data
is inserted as I have a few complex (by my standards) relationships
that would benefit from that sort of functionality.
On Fri, 2009-01-09 at 03:33 -0800, rabbi wrote:
> Is there a way to specify a constraint on a model ManyToMany
> relationship?
>
> For example, if I wanted to define an Animal model that has a field
> which specifies which other animals it eats and I wanted to limited
> these animals_I_eat relati
Is there a way to specify a constraint on a model ManyToMany
relationship?
For example, if I wanted to define an Animal model that has a field
which specifies which other animals it eats and I wanted to limited
these animals_I_eat relationships to animals who's specie_name starts
with "x", how wo
Thanks for your reply Malcolm. I'll take a look at related fields.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscrib
On Mon, 2008-08-18 at 05:36 -0700, [EMAIL PROTECTED] wrote:
> Incase my question wasn't clear enough, as I had trouble describing
> it ...
>
> Can a different model access the manytomany table that django makes ?
No, but you're probably thinking about this on the wrong level. Think
about it in
Incase my question wasn't clear enough, as I had trouble describing
it ...
Can a different model access the manytomany table that django makes ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
T
class Peg(models.Model):
history = OneToManyField(class=PegEntry)
class Hole(models.Model):
peg = models.ForeignKey(class=Peg, blank=True, null=True)
class PegEntry(models.Model):
hole = models.ForeignKey(class=Hole)
start = models.DateTimeField()
end = models.DateTimeField()
I'm a recovering PHP developer and I'm looking at using Django for my
next project - I know how to accomplish the following in PHP (well,
technically it's mostly accomplished in SQL...) but I'd like to know
how difficult it would be to handle this in Django:
I'm trying to create a model for a cer
29 matches
Mail list logo
