Django ORM generating the wrong query for recent friends of an user

[Arthur Silva]

Here're my models


class PingUser(AbstractUser):
friends = models.ManyToManyField("self", through="Friendship", 
symmetrical=False)

class Friendship(TimestampedModel, SerializeMixin):
STATUS_CHOICES = (
("pending", "Pending"),
("friend", "Friend"),
("favorite", "Favorite")
)
user = models.ForeignKey(PingUser, related_name="friendships")
friend = models.ForeignKey(PingUser, 
related_name="friendships_reverse")
status = models.CharField(max_length=20, 
default=STATUS_CHOICES[0][0], choices=STATUS_CHOICES)

class Meta:
unique_together = [('user', 'friend')]



The code I'm using to get the most recent friends of user 4


id = 4
friendships = Friendship.objects.exclude(status="pending").filter(
~Q(user__friendships__status="pending"), 
user__friendships__friend_id=id).order_by("-created_at")


I also tried several combinations like grouping all filtering inside one 
filter() but the query is the same


Generated query


SELECT `sample_app_friendship`.`id`,
   `sample_app_friendship`.`created_at`,
   `sample_app_friendship`.`updated_at`,
   `sample_app_friendship`.`user_id`,
   `sample_app_friendship`.`friend_id`,
   `sample_app_friendship`.`status`
FROM `sample_app_friendship`
INNER JOIN `sample_app_pinguser` ON (`sample_app_friendship`.`user_id` 
= `sample_app_pinguser`.`id`)
INNER JOIN `sample_app_friendship` T5 ON (`sample_app_pinguser`.`id` = 
T5.`user_id`)
WHERE (NOT (`sample_app_friendship`.`status` = 'pending')
   AND NOT ((`sample_app_friendship`.`user_id` IN
   (SELECT U2.`user_id`
FROM `sample_app_friendship` U2
WHERE (U2.`status` = 'pending'
   AND U2.`user_id` IS NOT NULL))
 AND `sample_app_pinguser`.`id` IS NOT NULL))
   AND T5.`friend_id` = 4)



The desired query is actually


SELECT `sample_app_friendship`.`id`,
   `sample_app_friendship`.`created_at`,
   `sample_app_friendship`.`updated_at`,
   `sample_app_friendship`.`user_id`,
   `sample_app_friendship`.`friend_id`,
   `sample_app_friendship`.`status`
FROM `sample_app_friendship`
INNER JOIN `sample_app_pinguser` ON (`sample_app_friendship`.`user_id` 
= `sample_app_pinguser`.`id`)
INNER JOIN `sample_app_friendship` T5 ON (`sample_app_pinguser`.`id` = 
T5.`user_id`)
WHERE (NOT (`sample_app_friendship`.`status` = 'pending')
   AND (NOT T5.`status` = 'pending')
   AND T5.`friend_id` = 4)

Someone more experienced can shed some light?

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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Dig]

Hi,

  Please let me repeat my question shortly, I want to access the same
database from 2 different django project/app. Can anyone help me? Thanks.

Regards,
Dig
On Sep 20, 2013 9:13 PM, "Dig"  wrote:

> Hi,
>
>   There are about 20 views in a django project (with a django app).
> Recently, a new requirement occurred, someone want to split current views
> into 2 site but the database is unique. That means 2 subdomain, 2 views
> sets, 2 deployment scripts, but only one database.
>
> Can I implement this feature by writing 2 setting.py files?
>
> Environment:
>   Django 1.5.4
>   Nginx + uwsgi
>   MySQL
>
> Thanks,
> Dig
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Rafael E. Ferrero]

What trouble cause to you settings the same database in two differents
projects (mean configure the same database in two diferentes settings.py)??
im curious because i never need do that and think its usefull to know.

Cheers,


2013/9/24 Dig 

> Hi,
>
>   Please let me repeat my question shortly, I want to access the same
> database from 2 different django project/app. Can anyone help me? Thanks.
>
> Regards,
> Dig
> On Sep 20, 2013 9:13 PM, "Dig"  wrote:
>
>> Hi,
>>
>>   There are about 20 views in a django project (with a django app).
>> Recently, a new requirement occurred, someone want to split current views
>> into 2 site but the database is unique. That means 2 subdomain, 2 views
>> sets, 2 deployment scripts, but only one database.
>>
>> Can I implement this feature by writing 2 setting.py files?
>>
>> Environment:
>>   Django 1.5.4
>>   Nginx + uwsgi
>>   MySQL
>>
>> Thanks,
>> Dig
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Rafael E. Ferrero

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[François Schiettecatte]

Sure, just have the DATABASES entry in the settings.py files point to the same 
server/database, or to the same server and different databases.

François

On Sep 24, 2013, at 10:12 AM, Dig  wrote:

> Hi,
> 
>   Please let me repeat my question shortly, I want to access the same 
> database from 2 different django project/app. Can anyone help me? Thanks.
> 
> Regards,
> Dig
> 
> On Sep 20, 2013 9:13 PM, "Dig"  wrote:
> Hi,
> 
>   There are about 20 views in a django project (with a django app). Recently, 
> a new requirement occurred, someone want to split current views into 2 site 
> but the database is unique. That means 2 subdomain, 2 views sets, 2 
> deployment scripts, but only one database.
> 
> Can I implement this feature by writing 2 setting.py files?
> 
> Environment:
>   Django 1.5.4
>   Nginx + uwsgi
>   MySQL
> 
> Thanks,
> Dig
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to share model/data cross django project

[Dig]

Hi,

 Thanks for your reply.
I want to separate internal user and external user.
External user can use a http connection to see a few pages. (http only)
Internal user use a https connection to do some staff only operations.
(https only)
This site are deployed on AWS, and we want to leverage Security Group
(IPfirewall) to takes the restrict,
So I have to do build 2 different app for external user and internal user.

I know that I can implement this feature in app layer, but it will waste
more CPU.

Regards,
Dig


Regards,
Dig Ge


On Tue, Sep 24, 2013 at 10:21 PM, François Schiettecatte <
fschietteca...@gmail.com> wrote:

> Sure, just have the DATABASES entry in the settings.py files point to the
> same server/database, or to the same server and different databases.
>
> François
>
> On Sep 24, 2013, at 10:12 AM, Dig  wrote:
>
> > Hi,
> >
> >   Please let me repeat my question shortly, I want to access the same
> database from 2 different django project/app. Can anyone help me? Thanks.
> >
> > Regards,
> > Dig
> >
> > On Sep 20, 2013 9:13 PM, "Dig"  wrote:
> > Hi,
> >
> >   There are about 20 views in a django project (with a django app).
> Recently, a new requirement occurred, someone want to split current views
> into 2 site but the database is unique. That means 2 subdomain, 2 views
> sets, 2 deployment scripts, but only one database.
> >
> > Can I implement this feature by writing 2 setting.py files?
> >
> > Environment:
> >   Django 1.5.4
> >   Nginx + uwsgi
> >   MySQL
> >
> > Thanks,
> > Dig
> >
> >
> > --
> > 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.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Rafael E. Ferrero]

seems to me that you can setup the same database in the two settings.py of
your two projects.




2013/9/24 Dig 

> Hi,
>
>  Thanks for your reply.
> I want to separate internal user and external user.
> External user can use a http connection to see a few pages. (http only)
> Internal user use a https connection to do some staff only operations.
> (https only)
> This site are deployed on AWS, and we want to leverage Security Group 
> (IPfirewall) to takes the restrict,
> So I have to do build 2 different app for external user and internal user.
>
> I know that I can implement this feature in app layer, but it will waste
> more CPU.
>
> Regards,
> Dig
>
>
> Regards,
> Dig Ge
>
>
> On Tue, Sep 24, 2013 at 10:21 PM, François Schiettecatte <
> fschietteca...@gmail.com> wrote:
>
>> Sure, just have the DATABASES entry in the settings.py files point to the
>> same server/database, or to the same server and different databases.
>>
>> François
>>
>> On Sep 24, 2013, at 10:12 AM, Dig  wrote:
>>
>> > Hi,
>> >
>> >   Please let me repeat my question shortly, I want to access the same
>> database from 2 different django project/app. Can anyone help me? Thanks.
>> >
>> > Regards,
>> > Dig
>> >
>> > On Sep 20, 2013 9:13 PM, "Dig"  wrote:
>> > Hi,
>> >
>> >   There are about 20 views in a django project (with a django app).
>> Recently, a new requirement occurred, someone want to split current views
>> into 2 site but the database is unique. That means 2 subdomain, 2 views
>> sets, 2 deployment scripts, but only one database.
>> >
>> > Can I implement this feature by writing 2 setting.py files?
>> >
>> > Environment:
>> >   Django 1.5.4
>> >   Nginx + uwsgi
>> >   MySQL
>> >
>> > Thanks,
>> > Dig
>> >
>> >
>> > --
>> > 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.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Rafael E. Ferrero

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Frank Bieniek]

Hi Dig,
you want to have different permissions actions depending on the user, 
that accesses the data,
but it is the the same data - correct? if so you are speaking about one 
app not two.
One App, as it is the same data, but different views, related to the 
context you are accessing it.


Do you have investigated django guardian - object level permissions?

Thanks
Frank








Am 24.09.2013 16:12, schrieb Dig:


Hi,

  Please let me repeat my question shortly, I want to access the same 
database from 2 different django project/app. Can anyone help me? Thanks.


Regards,
Dig

On Sep 20, 2013 9:13 PM, "Dig" > wrote:


Hi,

  There are about 20 views in a django project (with a django
app). Recently, a new requirement occurred, someone want to split
current views into 2 site but the database is unique. That means 2
subdomain, 2 views sets, 2 deployment scripts, but only one database.

Can I implement this feature by writing 2 setting.py files?

Environment:
  Django 1.5.4
  Nginx + uwsgi
  MySQL

Thanks,
Dig

--
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.
For more options, visit https://groups.google.com/groups/opt_out.


--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Dig]

Hi,

  And how about models.py? Makes a copy?

Thanks.

Regards,
Dig


Regards,
Dig Ge


On Tue, Sep 24, 2013 at 11:51 PM, Rafael E. Ferrero <
rafael.ferr...@gmail.com> wrote:

> seems to me that you can setup the same database in the two settings.py of
> your two projects.
>
>
>
>
> 2013/9/24 Dig 
>
>> Hi,
>>
>>  Thanks for your reply.
>> I want to separate internal user and external user.
>> External user can use a http connection to see a few pages. (http only)
>> Internal user use a https connection to do some staff only operations.
>> (https only)
>> This site are deployed on AWS, and we want to leverage Security Group 
>> (IPfirewall) to takes the restrict,
>> So I have to do build 2 different app for external user and internal user.
>>
>> I know that I can implement this feature in app layer, but it will waste
>> more CPU.
>>
>> Regards,
>> Dig
>>
>>
>> Regards,
>> Dig Ge
>>
>>
>> On Tue, Sep 24, 2013 at 10:21 PM, François Schiettecatte <
>> fschietteca...@gmail.com> wrote:
>>
>>> Sure, just have the DATABASES entry in the settings.py files point to
>>> the same server/database, or to the same server and different databases.
>>>
>>> François
>>>
>>> On Sep 24, 2013, at 10:12 AM, Dig  wrote:
>>>
>>> > Hi,
>>> >
>>> >   Please let me repeat my question shortly, I want to access the same
>>> database from 2 different django project/app. Can anyone help me? Thanks.
>>> >
>>> > Regards,
>>> > Dig
>>> >
>>> > On Sep 20, 2013 9:13 PM, "Dig"  wrote:
>>> > Hi,
>>> >
>>> >   There are about 20 views in a django project (with a django app).
>>> Recently, a new requirement occurred, someone want to split current views
>>> into 2 site but the database is unique. That means 2 subdomain, 2 views
>>> sets, 2 deployment scripts, but only one database.
>>> >
>>> > Can I implement this feature by writing 2 setting.py files?
>>> >
>>> > Environment:
>>> >   Django 1.5.4
>>> >   Nginx + uwsgi
>>> >   MySQL
>>> >
>>> > Thanks,
>>> > Dig
>>> >
>>> >
>>> > --
>>> > 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.
>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>  --
>> 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.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Rafael E. Ferrero
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Django Templates: Using the "with" statement and "block.super" together

[Warren Smith]

On occasion, I've used the following technique in my django templates:

# parent.html 

{% block someblock %}
…stuff…
  {% if cool_optional_feature_is_enabled %}
…optional stuff...
  {% endif %}
…stuff...
{% endblock %}


# child.html
{% extends "parent.html" %}

{% block someblock %}
  {% with True as cool_optional_feature_is_enabled %}
{{ block.super }}
  {% endwith %}
{% endblock %}


The cool thing is that this technique allows a child template to 
essentially enable a feature in the parent template. The same technique can 
also be used to disable a feature in the parent template, or really 
anything that can be driven from a context variable, since, as I understand 
it, that is what the with statement is doing: temporarily injecting a 
variable into the context within which the expressions in a chunk of 
template code are evaluated against.

I was showing this to a colleague today and, though he thought it was neat, 
he had never seen it before and was concerned that it was not a mainstream 
use of the django template language. I did some cursory google searches and 
couldn't find any overt references to this ability either.

My concern is that I may be relying on some undocumented side-effect of the 
way that blocks or the with statement are implemented and that, at some 
point in the future, this will be changed and all of my templates that use 
this will break.
 

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Templates: Using the "with" statement and "block.super" together

[Bill Freeman]

This sounds safe to me.  After all, we pass context variables in from views
and expect them to be available within block.super code.

Perhaps some folks aren't sufficiently clear as to when stuff in a template
is evaluated.

So, I'd do it if I needed it.


On Tue, Sep 24, 2013 at 1:59 PM, Warren Smith  wrote:

> On occasion, I've used the following technique in my django templates:
>
> # parent.html
>
> {% block someblock %}
> …stuff…
>   {% if cool_optional_feature_is_enabled %}
> …optional stuff...
>   {% endif %}
> …stuff...
> {% endblock %}
>
>
> # child.html
> {% extends "parent.html" %}
>
> {% block someblock %}
>   {% with True as cool_optional_feature_is_enabled %}
> {{ block.super }}
>   {% endwith %}
> {% endblock %}
>
>
> The cool thing is that this technique allows a child template to
> essentially enable a feature in the parent template. The same technique can
> also be used to disable a feature in the parent template, or really
> anything that can be driven from a context variable, since, as I understand
> it, that is what the with statement is doing: temporarily injecting a
> variable into the context within which the expressions in a chunk of
> template code are evaluated against.
>
> I was showing this to a colleague today and, though he thought it was
> neat, he had never seen it before and was concerned that it was not a
> mainstream use of the django template language. I did some cursory google
> searches and couldn't find any overt references to this ability either.
>
> My concern is that I may be relying on some undocumented side-effect of
> the way that blocks or the with statement are implemented and that, at some
> point in the future, this will be changed and all of my templates that use
> this will break.
>
>
> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Templates: Using the "with" statement and "block.super" together

[Tomas Ehrlich]

I use it too.

Maybe it would be nice to document it somewhere.


Cheers,
  Tom


Dne Tue, 24 Sep 2013 10:59:27 -0700 (PDT)
Warren Smith  napsal(a):

> On occasion, I've used the following technique in my django templates:
> 
> # parent.html 
> 
> {% block someblock %}
> …stuff…
>   {% if cool_optional_feature_is_enabled %}
> …optional stuff...
>   {% endif %}
> …stuff...
> {% endblock %}
> 
> 
> # child.html
> {% extends "parent.html" %}
> 
> {% block someblock %}
>   {% with True as cool_optional_feature_is_enabled %}
> {{ block.super }}
>   {% endwith %}
> {% endblock %}
> 
> 
> The cool thing is that this technique allows a child template to 
> essentially enable a feature in the parent template. The same technique can 
> also be used to disable a feature in the parent template, or really 
> anything that can be driven from a context variable, since, as I understand 
> it, that is what the with statement is doing: temporarily injecting a 
> variable into the context within which the expressions in a chunk of 
> template code are evaluated against.
> 
> I was showing this to a colleague today and, though he thought it was neat, 
> he had never seen it before and was concerned that it was not a mainstream 
> use of the django template language. I did some cursory google searches and 
> couldn't find any overt references to this ability either.
> 
> My concern is that I may be relying on some undocumented side-effect of the 
> way that blocks or the with statement are implemented and that, at some 
> point in the future, this will be changed and all of my templates that use 
> this will break.
>  
> 


signature.asc
Description: PGP signature

Aggregation and count - only counting certain related models? (i.e. adding a filter on the count)

[Victor Hooi]

Hi,

I'm trying to use aggregation to count the number of "likes" on an item.

The likes for an item are stored in a related model, called LikeStatus:

class Item(models.Model):
> ...
> class ItemLikeStatus(models.Model):
> LIKE_STATUS_CHOICES = (
> ('L', 'Liked'),
> ('U', 'Unliked'),
> ('A', 'Abstained (no vote)'),
> ('N', 'Not seen yet'),
> )
> user = models.ForeignKey(User)
> item = models.ForeignKey(Item)
> liked_status = models.CharField(max_length=1, 
> choices=LIKE_STATUS_CHOICES)


I'm using the following aggregation:

items_by_popularity = 
> Item.objects.all().annotate(Count('itemlikestatus')).order_by('-itemlikestatus__count')[:number_requested]


However, I would like to count up only the like statuses where the 
liked_status code is "L".

My thoughts are that I can iterate through the entire Item set myself and 
do a filter on the related itemlikestatus for each Item, and produce the 
aggregation by hand. However, that seems like a silly way to do it, and 
doesn't really use the database.

I was wondering if there's a smarter way to still use aggregation, but 
filter out to only count a subset of related ItemLikeStatus?

Cheers,
Victor

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Restrict access to user-uploaded files to authorized users

[J Y]

I am buliding a tool that needs to have the ability to allow user to upload 
a file, and the file should only be accessible by the user who uploaded it. 
 It seems that the MEDIA_ROOT directory must be placed in the public www 
directory for front end web servers Apache to serve the file, which 
currently does not restrict access to any of the uploaded files.  What I am 
looking for is a way that I can lock it down so that if they try to access 
the file directly, I would bring up a login screen and they must 
authenticate before I give them access to it.

I did some searching around, and found various solutions to the problem, 
but none of them sounds like it would work for me.  My requirements are:

1. My front-end web server must be Apache
2. Apache setup and config cannot be changed to accommodate my site alone 
(unless it's a config I can easily override in .htaccess)
3. Users should not have to log in twice (If they authenticated against 
django already, no reason to ask them to login to Apache again)
3. Use django to serve the files as a last resort

Here are some of the solutions I found:

1. Update nginx/apache config to hook into django's user's database.  This 
looks like it would ask the user to login again via Apache's login 
mechanism, plus it doesn't look like it would work with alternative 
authentication backend (I am using django-auth-ldap)
2. Use django-sendfile, not possible because it requires installing plugins 
to Apache
3. Serve files through django.  Not recommended by django, so I am loath to 
try it
4. Override the MEDIA_ROOT behavior in urls.py and implement my own file 
serving behavior.  This sounds not all that far off from #3.

Are there any obvious solutions that I have over looked?  Or am I stuck 
having to use django to serve the files?

Thanks for any advice,

Jack

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Aggregation and count - only counting certain related models? (i.e. adding a filter on the count)

[Simon Charette]

Unfortunately the Django ORM's doesn't support conditionnal 
aggregates
.

Le mardi 24 septembre 2013 16:50:51 UTC-4, Victor Hooi a écrit :
>
> Hi,
>
> I'm trying to use aggregation to count the number of "likes" on an item.
>
> The likes for an item are stored in a related model, called LikeStatus:
>
> class Item(models.Model):
>> ...
>> class ItemLikeStatus(models.Model):
>> LIKE_STATUS_CHOICES = (
>> ('L', 'Liked'),
>> ('U', 'Unliked'),
>> ('A', 'Abstained (no vote)'),
>> ('N', 'Not seen yet'),
>> )
>> user = models.ForeignKey(User)
>> item = models.ForeignKey(Item)
>> liked_status = models.CharField(max_length=1, 
>> choices=LIKE_STATUS_CHOICES)
>
>
> I'm using the following aggregation:
>
> items_by_popularity = 
>> Item.objects.all().annotate(Count('itemlikestatus')).order_by('-itemlikestatus__count')[:number_requested]
>
>
> However, I would like to count up only the like statuses where the 
> liked_status code is "L".
>
> My thoughts are that I can iterate through the entire Item set myself and 
> do a filter on the related itemlikestatus for each Item, and produce the 
> aggregation by hand. However, that seems like a silly way to do it, and 
> doesn't really use the database.
>
> I was wondering if there's a smarter way to still use aggregation, but 
> filter out to only count a subset of related ItemLikeStatus?
>
> Cheers,
> Victor
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Aggregation and count - only counting certain related models? (i.e. adding a filter on the count)

[Simon Charette]

Unfortunately the Django ORM's doesn't support conditionnal 
aggregates
.

Le mardi 24 septembre 2013 16:50:51 UTC-4, Victor Hooi a écrit :
>
> Hi,
>
> I'm trying to use aggregation to count the number of "likes" on an item.
>
> The likes for an item are stored in a related model, called LikeStatus:
>
> class Item(models.Model):
>> ...
>> class ItemLikeStatus(models.Model):
>> LIKE_STATUS_CHOICES = (
>> ('L', 'Liked'),
>> ('U', 'Unliked'),
>> ('A', 'Abstained (no vote)'),
>> ('N', 'Not seen yet'),
>> )
>> user = models.ForeignKey(User)
>> item = models.ForeignKey(Item)
>> liked_status = models.CharField(max_length=1, 
>> choices=LIKE_STATUS_CHOICES)
>
>
> I'm using the following aggregation:
>
> items_by_popularity = 
>> Item.objects.all().annotate(Count('itemlikestatus')).order_by('-itemlikestatus__count')[:number_requested]
>
>
> However, I would like to count up only the like statuses where the 
> liked_status code is "L".
>
> My thoughts are that I can iterate through the entire Item set myself and 
> do a filter on the related itemlikestatus for each Item, and produce the 
> aggregation by hand. However, that seems like a silly way to do it, and 
> doesn't really use the database.
>
> I was wondering if there's a smarter way to still use aggregation, but 
> filter out to only count a subset of related ItemLikeStatus?
>
> Cheers,
> Victor
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Restrict access to user-uploaded files to authorized users

[Simon Charette]

I'm not aware of any solution except serving from Django if you can't 
install Apache plugins.

If you're really stuck with serving large files from Django I'd recommend 
you 
streamthe
 content of the file instead of loading its content in memory.

But you *really *shouldn't serve large files from Django.

Le mardi 24 septembre 2013 16:53:58 UTC-4, J Y a écrit :
>
> I am buliding a tool that needs to have the ability to allow user to 
> upload a file, and the file should only be accessible by the user who 
> uploaded it.  It seems that the MEDIA_ROOT directory must be placed in the 
> public www directory for front end web servers Apache to serve the file, 
> which currently does not restrict access to any of the uploaded files. 
>  What I am looking for is a way that I can lock it down so that if they try 
> to access the file directly, I would bring up a login screen and they must 
> authenticate before I give them access to it.
>
> I did some searching around, and found various solutions to the problem, 
> but none of them sounds like it would work for me.  My requirements are:
>
> 1. My front-end web server must be Apache
> 2. Apache setup and config cannot be changed to accommodate my site alone 
> (unless it's a config I can easily override in .htaccess)
> 3. Users should not have to log in twice (If they authenticated against 
> django already, no reason to ask them to login to Apache again)
> 3. Use django to serve the files as a last resort
>
> Here are some of the solutions I found:
>
> 1. Update nginx/apache config to hook into django's user's database.  This 
> looks like it would ask the user to login again via Apache's login 
> mechanism, plus it doesn't look like it would work with alternative 
> authentication backend (I am using django-auth-ldap)
> 2. Use django-sendfile, not possible because it requires installing 
> plugins to Apache
> 3. Serve files through django.  Not recommended by django, so I am loath 
> to try it
> 4. Override the MEDIA_ROOT behavior in urls.py and implement my own file 
> serving behavior.  This sounds not all that far off from #3.
>
> Are there any obvious solutions that I have over looked?  Or am I stuck 
> having to use django to serve the files?
>
> Thanks for any advice,
>
> Jack
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Templates: Using the "with" statement and "block.super" together

[Vijay Katam]

Seems legit to me. Some documentation could help get more usage.

On Tuesday, September 24, 2013 12:59:27 PM UTC-5, Warren Smith wrote:
>
> On occasion, I've used the following technique in my django templates:
>
> # parent.html 
>
> {% block someblock %}
> …stuff…
>   {% if cool_optional_feature_is_enabled %}
> …optional stuff...
>   {% endif %}
> …stuff...
> {% endblock %}
>
>
> # child.html
> {% extends "parent.html" %}
>
> {% block someblock %}
>   {% with True as cool_optional_feature_is_enabled %}
> {{ block.super }}
>   {% endwith %}
> {% endblock %}
>
>
> The cool thing is that this technique allows a child template to 
> essentially enable a feature in the parent template. The same technique can 
> also be used to disable a feature in the parent template, or really 
> anything that can be driven from a context variable, since, as I understand 
> it, that is what the with statement is doing: temporarily injecting a 
> variable into the context within which the expressions in a chunk of 
> template code are evaluated against.
>
> I was showing this to a colleague today and, though he thought it was 
> neat, he had never seen it before and was concerned that it was not a 
> mainstream use of the django template language. I did some cursory google 
> searches and couldn't find any overt references to this ability either.
>
> My concern is that I may be relying on some undocumented side-effect of 
> the way that blocks or the with statement are implemented and that, at some 
> point in the future, this will be changed and all of my templates that use 
> this will break.
>  
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Restrict access to user-uploaded files to authorized users

[m1chael]

mod_xsendfile for apache has worked for me, don't know if it will work for
you

On Tue, Sep 24, 2013 at 5:08 PM, Simon Charette wrote:

> I'm not aware of any solution except serving from Django if you can't
> install Apache plugins.
>
> If you're really stuck with serving large files from Django I'd recommend
> you 
> streamthe
>  content of the file instead of loading its content in memory.
>
> But you *really *shouldn't serve large files from Django.
>
> Le mardi 24 septembre 2013 16:53:58 UTC-4, J Y a écrit :
>
>> I am buliding a tool that needs to have the ability to allow user to
>> upload a file, and the file should only be accessible by the user who
>> uploaded it.  It seems that the MEDIA_ROOT directory must be placed in the
>> public www directory for front end web servers Apache to serve the file,
>> which currently does not restrict access to any of the uploaded files.
>>  What I am looking for is a way that I can lock it down so that if they try
>> to access the file directly, I would bring up a login screen and they must
>> authenticate before I give them access to it.
>>
>> I did some searching around, and found various solutions to the problem,
>> but none of them sounds like it would work for me.  My requirements are:
>>
>> 1. My front-end web server must be Apache
>> 2. Apache setup and config cannot be changed to accommodate my site alone
>> (unless it's a config I can easily override in .htaccess)
>> 3. Users should not have to log in twice (If they authenticated against
>> django already, no reason to ask them to login to Apache again)
>> 3. Use django to serve the files as a last resort
>>
>> Here are some of the solutions I found:
>>
>> 1. Update nginx/apache config to hook into django's user's database.
>>  This looks like it would ask the user to login again via Apache's login
>> mechanism, plus it doesn't look like it would work with alternative
>> authentication backend (I am using django-auth-ldap)
>> 2. Use django-sendfile, not possible because it requires installing
>> plugins to Apache
>> 3. Serve files through django.  Not recommended by django, so I am loath
>> to try it
>> 4. Override the MEDIA_ROOT behavior in urls.py and implement my own file
>> serving behavior.  This sounds not all that far off from #3.
>>
>> Are there any obvious solutions that I have over looked?  Or am I stuck
>> having to use django to serve the files?
>>
>> Thanks for any advice,
>>
>> Jack
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to share model/data cross django project

[Dig]

Hi Frank,

  Thank you for your reply. I can implement this feature in app layer, but
I won't do it to waste CPU. It can be done in IP firewall, so I prefer
laverge it.

Regards,
Dig
On Sep 25, 2013 12:21 AM, "Frank Bieniek" 
wrote:

>  Hi Dig,
> you want to have different permissions actions depending on the user, that
> accesses the data,
> but it is the the same data - correct? if so you are speaking about one
> app not two.
> One App, as it is the same data, but different views, related to the
> context you are accessing it.
>
> Do you have investigated django guardian - object level permissions?
>
> Thanks
> Frank
>
>
>
>
>
>
>
>
> Am 24.09.2013 16:12, schrieb Dig:
>
> Hi,
>
>   Please let me repeat my question shortly, I want to access the same
> database from 2 different django project/app. Can anyone help me? Thanks.
>
> Regards,
> Dig
> On Sep 20, 2013 9:13 PM, "Dig"  wrote:
>
>> Hi,
>>
>>   There are about 20 views in a django project (with a django app).
>> Recently, a new requirement occurred, someone want to split current views
>> into 2 site but the database is unique. That means 2 subdomain, 2 views
>> sets, 2 deployment scripts, but only one database.
>>
>> Can I implement this feature by writing 2 setting.py files?
>>
>> Environment:
>>   Django 1.5.4
>>   Nginx + uwsgi
>>   MySQL
>>
>> Thanks,
>> Dig
>>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>  --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Templates: Using the "with" statement and "block.super" together

[Russell Keith-Magee]

On Wed, Sep 25, 2013 at 1:59 AM, Warren Smith  wrote:

> On occasion, I've used the following technique in my django templates:
>
> # parent.html
>
> {% block someblock %}
> …stuff…
>   {% if cool_optional_feature_is_enabled %}
> …optional stuff...
>   {% endif %}
> …stuff...
> {% endblock %}
>
>
> # child.html
> {% extends "parent.html" %}
>
> {% block someblock %}
>   {% with True as cool_optional_feature_is_enabled %}
> {{ block.super }}
>   {% endwith %}
> {% endblock %}
>
>
> The cool thing is that this technique allows a child template to
> essentially enable a feature in the parent template. The same technique can
> also be used to disable a feature in the parent template, or really
> anything that can be driven from a context variable, since, as I understand
> it, that is what the with statement is doing: temporarily injecting a
> variable into the context within which the expressions in a chunk of
> template code are evaluated against.
>
> I was showing this to a colleague today and, though he thought it was
> neat, he had never seen it before and was concerned that it was not a
> mainstream use of the django template language. I did some cursory google
> searches and couldn't find any overt references to this ability either.
>
> My concern is that I may be relying on some undocumented side-effect of
> the way that blocks or the with statement are implemented and that, at some
> point in the future, this will be changed and all of my templates that use
> this will break.
>

As far as I can make out, this is exactly how blocks are intended to work
-- you're not relying on anything edge case here.

Finding documentation for this will be a little hard, because it's a bit of
an abstract concept. However, there have been plenty of tickets closed as
"not a bug" around related template parsing issues.

At the core of why this works -- In conceptual terms, template blocks have
higher precedence than any other tag in Django's template language. Blocks
are resolved first; once blocks have been resolved the rest of the
template, and all other template tags, are resolved with equal precedence.
(It's a little more complex than this when you get to the internals, but
this will do as a first-order approximation of what happens).

So in this case -- the block set up a structure that puts the content of
the parent into child.html, which means, as you put it, the child enables a
feature in the base.

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.
For more options, visit https://groups.google.com/groups/opt_out.