Re: Deprecate FCGI support in Django 1.7
On 15 juil. 2013, at 23:45, Jacob Kaplan-Moss wrote: > Let's start FCGI (and the others) down the path to deprecation. If there's > truly a community that finds value in these things -- and frankly I think > that once they try modern options they'll quickly switch and never look back > -- then let them maintain the code. OK, I'm convinced, let's do that! -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: 'LIKE' statement in Model.objects.raw() using percentage '%'
This is a mailing list for developing of django itself.
For usage of django please use the django-user mailing list.
Jorge
On Jul 17, 2013, at 4:21 PM, spondbob squelpen wrote:
> I have problem in django using query statement "LIKE %s%" with
> Model.objects.raw(). I guess the problem is on '%' character but i don't know
> where is it. Here's my model's code:
>
> def listInRange(self, placeLat, placeLng, typeId, range, placeTag):
> tags = ''
> if placeTag:
> tags = " AND (placeTag LIKE '%" + "%' OR placeTag LIKE
> '%".join(placeTag.split(',')) + "%')"
>
> query = "SELECT *, \
> ( \
> 6371000 * \
> acos( \
> cos( radians(%s) ) * \
> cos( radians(placeLat) ) * \
> cos( radians(placeLng) - radians(%s) ) + \
> sin( radians(%s) ) * \
> sin( radians(placeLat) ) \
> ) \
> ) AS placeDistance, \
> COUNT(r.reviewId) as placeReviews, \
>
> (SUM(r.reviewPointPrice)/COUNT(r.reviewId)+SUM(r.reviewPointService)/COUNT(r.reviewId)+SUM(r.reviewPointLocation)/COUNT(r.reviewId)+SUM(r.reviewPointCondition)/COUNT(r.reviewId)+SUM(r.reviewPointComfort)/COUNT(r.reviewId))/5
> AS averagePoint \
> FROM place_place p \
> LEFT JOIN review_review r \
> ON r.reviewPlace_id = p.placeId\
> WHERE placeType_id = %s %s \
> GROUP BY p.placeId \
> HAVING placeDistance < %s \
> ORDER BY placeDistance"
>
> return Place.objects.raw(query, [placeLat, placeLng, placeLat,
> typeId, tags, range])
>
> If placeTag is not empty, then it will added to the WHERE condition. When the
> placeTag is empty there's no such problem, but when placeTag is not empty i
> got this error :
>
> Warning: Truncated incorrect DOUBLE value: '1 AND (placeTag LIKE '%cafe%'
> OR placeTag LIKE '%pub%')'
>
> I think python make '1 AND (placeTag LIKE '%cafe%' OR placeTag LIKE '%pub%')'
> as the value for placeType_id. How can i make the value of placeType_id=1 and
> add the AND statement? What's the better way to write the sql statement using
> Model.objects.raw() with 'like' statement?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
'LIKE' statement in Model.objects.raw() using percentage '%'
I have problem in django using query statement "LIKE %s%" with
Model.objects.raw(). I guess the problem is on '%' character but i don't
know where is it. Here's my model's code:
def listInRange(self, placeLat, placeLng, typeId, range, placeTag):
tags = ''
if placeTag:
tags = " AND (placeTag LIKE '%" + "%' OR placeTag LIKE
'%".join(placeTag.split(',')) + "%')"
query = "SELECT *, \
( \
6371000 * \
acos( \
cos( radians(%s) ) * \
cos( radians(placeLat) ) * \
cos( radians(placeLng) - radians(%s) ) + \
sin( radians(%s) ) * \
sin( radians(placeLat) ) \
) \
) AS placeDistance, \
COUNT(r.reviewId) as placeReviews, \
(SUM(r.reviewPointPrice)/COUNT(r.reviewId)+SUM(r.reviewPointService)/COUNT(r.reviewId)+SUM(r.reviewPointLocation)/COUNT(r.reviewId)+SUM(r.reviewPointCondition)/COUNT(r.reviewId)+SUM(r.reviewPointComfort)/COUNT(r.reviewId))/5
AS averagePoint \
FROM place_place p \
LEFT JOIN review_review r \
ON r.reviewPlace_id = p.placeId\
WHERE placeType_id = %s %s \
GROUP BY p.placeId \
HAVING placeDistance < %s \
ORDER BY placeDistance"
return Place.objects.raw(query, [placeLat, placeLng, placeLat,
typeId, tags, range])
If placeTag is not empty, then it will added to the WHERE condition. When
the placeTag is empty there's no such problem, but when placeTag is not
empty i got this error :
Warning: Truncated incorrect DOUBLE value: '1 AND (placeTag LIKE
'%cafe%' OR placeTag LIKE '%pub%')'
I think python make '1 AND (placeTag LIKE '%cafe%' OR placeTag LIKE '%pub%')'
as the value for placeType_id. How can i make the value of placeType_id=1
and add the AND statement? What's the better way to write the sql statement
using Model.objects.raw() with 'like' statement?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Hybrid Property request
On 17 July 2013 21:18, Jonathan Slenders wrote: > This is really nice. Both have their use cases, but I'm prefering the > second when possible, because it's much more flexible and preserves > database consistency. > With the same efford you can make the following work: > > ProductEntry.objects.filter(lambda p: p.onpurchase_price * p.quantity > == 5000.0) > > Or if you don't like the lambda keyword, extend the Q object. Something > like this: > > ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0) > > ISTM it would be more of an extension of ExpressionNode, like F(). -- Curtis -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Hybrid Property request
Oh, and denormalisation is not necessarily faster. If you're able to express the value of the column as an SQL expression, it's possible to put an index on such an expression. Le mercredi 17 juillet 2013 13:18:16 UTC+2, Jonathan Slenders a écrit : > > This is really nice. Both have their use cases, but I'm prefering the > second when possible, because it's much more flexible and preserves > database consistency. > With the same efford you can make the following work: > > ProductEntry.objects.filter(lambda p: p.onpurchase_price * p.quantity > == 5000.0) > > Or if you don't like the lambda keyword, extend the Q object. Something > like this: > > ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0) > > > Denormalisation is fine if you often do the same query. It's certainly > easier to implement, but I wouldn't encourage it too much. > > > > Le mercredi 17 juillet 2013 03:15:52 UTC+2, Alex_Gaynor a écrit : >> >> I'm going to suggest that a virtual field and a materialized field are >> slightly different concepts, and porblaly have different internals. The >> former requires some hooks in the ORM, the latter is really just some nice >> wrapping around existing hooks. >> >> In any event there's probably some overal with the composite fields GSOC >> for the virtual field, when we generalize fields to N>=1, I'm hoping that >> makes generlaizing them to N=0 easier. >> >> Alex >> >> >> On Wed, Jul 17, 2013 at 11:12 AM, Jacob Kaplan-Moss >> wrote: >> >>> On Tue, Jul 16, 2013 at 8:04 PM, Russell Keith-Magee < >>> rus...@keith-magee.com> wrote: >>> So - functionally, what you describe can be done. What's missing is someone to polish the concepts into a patch for inclusion into Django's repository. If this is something that interests you - get hacking! :-) >>> >>> I'll bet, in fact, that you could do *both* of these things in a >>> *single* implementation. A hybrid property (to use your term) with a >>> virtual/concrete flag sounds epic. Show me a good patch and I'll help get >>> it merged! >>> >>> :) >>> >>> Jacob >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> >> >> -- >> "I disapprove of what you say, but I will defend to the death your right >> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) >> "The people's good is the highest law." -- Cicero >> GPG Key fingerprint: 125F 5C67 DFE9 4084 >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Hybrid Property request
This is really nice. Both have their use cases, but I'm prefering the second when possible, because it's much more flexible and preserves database consistency. With the same efford you can make the following work: ProductEntry.objects.filter(lambda p: p.onpurchase_price * p.quantity == 5000.0) Or if you don't like the lambda keyword, extend the Q object. Something like this: ProductEntry.objects.filter(Q(onpurchase_price) * Q(quantity) == 5000.0) Denormalisation is fine if you often do the same query. It's certainly easier to implement, but I wouldn't encourage it too much. Le mercredi 17 juillet 2013 03:15:52 UTC+2, Alex_Gaynor a écrit : > > I'm going to suggest that a virtual field and a materialized field are > slightly different concepts, and porblaly have different internals. The > former requires some hooks in the ORM, the latter is really just some nice > wrapping around existing hooks. > > In any event there's probably some overal with the composite fields GSOC > for the virtual field, when we generalize fields to N>=1, I'm hoping that > makes generlaizing them to N=0 easier. > > Alex > > > On Wed, Jul 17, 2013 at 11:12 AM, Jacob Kaplan-Moss > > > wrote: > >> On Tue, Jul 16, 2013 at 8:04 PM, Russell Keith-Magee < >> rus...@keith-magee.com > wrote: >> >>> So - functionally, what you describe can be done. What's missing is >>> someone to polish the concepts into a patch for inclusion into Django's >>> repository. If this is something that interests you - get hacking! :-) >>> >> >> I'll bet, in fact, that you could do *both* of these things in a *single* >> implementation. A hybrid property (to use your term) with a >> virtual/concrete flag sounds epic. Show me a good patch and I'll help get >> it merged! >> >> :) >> >> Jacob >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-develop...@googlegroups.com . >> To post to this group, send email to >> django-d...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/django-developers. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSoC] Revamping validation framework and merging django-secure once again
I've created a pull request [1] to make deep review easier. I've rolled out tests we were talking about and reverted `validate_field` -- there exist both `check_field` and `validate_field`, the first calling the second. [1] https://github.com/django/django/pull/1364 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSoC] Revamping validation framework and merging django-secure once again
On Mon, Jul 15, 2013 at 8:17 PM, Christopher Medrela < chris.medr...@gmail.com> wrote: > Progress: I've implemented manager checks. > > The schedule for the next 4 weeks is: > > 1. Manager checks (ref 4.1.7)(done)(0.5 week). > 2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering >checking framework (ref 4.1.9)(1.5 week). > 3. Moving custom User model checks (ref 4.1.6)(0.5 week). > 4. Rewriting AdminModel checks and tests (ref 4.1.8)(1 week). > 5. Polishing doc (ref 4.1.10)(0.5 week). > > (ref 4.1.x are references to my original proposal [1]) > > [1] https://gist.github.com/chrismedrela/82cbda8d2a78a280a129) > > Let's talk about public API to register your own validation stuff. There > will > be `register(callable)` function in `django.core.checks`. It will return > nothing. The callables will be stored in a global variable. They should > obey > the same contract as `check` methods: they allow for `**kwargs` and return > list of errors and warnings. All registered callables will be called during > checking phase (i. e. when you type `manage.py validate` or before running > server). > I think you're on the right track here. The only other viable approach I can think of would be a setting (SYSTEM_CHECKS) that is a list of functions to be invoked. However, this means installing a new app that contained a set of checks would mean modifying multiple settings (INSTALLED_APPS, SYSTEM_CHECKS, and possibly others for templates etc) This is also true of the registration approach -- the only difference is where you put the call to register. However, looking into the medium-term future, app refactor will eventually land, and at that point, we'll have a natural point to put all these registrations -- the app definition itself would be able to register the additional checks. To that end, I think a registration based approach will ultimately be better. And it isn't something that most users will be exposed to anyway -- all the pre-existing checks can be pre-registered, and admin can do it's registration as part of the autodiscover process. This API allows us to register, among other things, app-specific checks. But > it's not necessary to write an app in order to do some checks. > > `register` function will have two optional parameters: `run_in_production` > (default: False) and `run_in_development` (default: True) that let you > specify > when the callable should be called. Most checks should be performed only in > development environment (which is equivalent to DEBUG==True). Security > checks > makes sense only in production environment (<==> DEBUG==False). > > I would be happy if I could hear your opinion! > I don't think we need to worry about 'in production' level checks at time of registration. The default behaviour should always be to run all checks when ./manage.py check is invoked. There are some very specific checks (such as security checks) that only make sense in production, but they're the exception, not the rule. These checks could be skipped using a decorator when they're defined - essentially: def only_in_production(fn): def _dec(*args, **kwargs): if settings.DEBUG == False: return fn(*args, **kwargs) return [] return _dec @only_in_production def security_checks(…): … This decorator could be applied to the security check, so it becomes a no-op when it is executed in development. This can be determined by the check itself - I can't think of any circumstance where a user registering a check would need to have control over whether a check would be executed at all. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: [GSoC] Revamping validation framework and merging django-secure once again
Hi Chris, On Fri, Jul 12, 2013 at 7:45 PM, Christopher Medrela < chris.medr...@gmail.com> wrote: > Finally, I've rewritten all model and field tests and checks. Some new > tests > were written. First draft of checking framework documentation was written. > All > tests passes (at least at my computer). I've rebased my branch > (`gsoc2013-checks` [1]) against master. The branch is ready to deep review. > > [1] https://github.com/chrismedrela/django/tree/gsoc2013-checks > This is looking good! If you issue a pull request for this branch, I'll add some detailed comments there. When you make the pull request, make sure you add a comment noting that this is a work in progress associated with the GSoC, and isn't a candidate for merging (yet!). > I've created pull request [2] for ticket [#19934]. The patch clarifies that > importing `django.utils.image` cannot result in ImportError. I've also > created > ticket [#20735] about confusing ManyToManyField documentation. There is a > pull > request too [3]. Both pull requests were merged. > > [2] https://github.com/django/django/pull/1349 > [3] https://github.com/django/django/pull/1350 > [#19934] https://code.djangoproject.com/ticket/19934 > [#20735] https://code.djangoproject.com/ticket/20735 > 1. I wrote some tests [4] where nose tests generators [5] would be really > helpful. I tried to emulate them. Is the code I wrote a good approach? > > [4] > https://github.com/chrismedrela/django/blob/1c14c674aa52c666ec8742c72657d5dad2efe0cb/tests/invalid_models/tests.py#L690 > [5] > https://nose.readthedocs.org/en/latest/writing_tests.html#test-generators > I can see what you're doing here, but it's probably not the best approach. As implemented, there are two problems: 1) there's going to be a redundant call to setUp and tearDown 2) you only get one opportunity for a failure in all the accessor_check tests. Given that you're only dealing with 6 tests (2 targets x 3 relatives) here, I'd be inclined to manually roll them out. When we've got Python 3.4 as a minimum dependency, we can start using subunit tests [1], but until then, we can live with a small amount of manual code rollout. [1] http://docs.python.org/dev/library/unittest.html#distinguishing-test-iterations-using-subtests > 2. Two m2m through the same model are forbidden. The new error message is: > > applabel.modelname: Two m2m relations through the same model. > The model has two many-to-many relations through the intermediary > Membership > model, which is not permitted. > (No hint.) > > > Is there any reasonable hint we can provide except for suggesting > duplicating > the intermediary model? > The hint is optional, so there's not much point having a hint unless it's actually providing useful information that isn't implicit in the error message. You can't have 2 m2m relations through the same intermediate model. The fix - don't have 2 m2m relations through the same intermediate model. The only practical advice we could give here would be to duplicate the intermediate model, but that doesn't strike me as something that is likely to be correct advice under most circumstances, so I'm hesitant to provide it as default advice. > 3. I've deleted `app_errors` [6] because it wasn't used anywhere (inside > Django). Was it left by accident or was there a reason for that? > > [6] > https://github.com/chrismedrela/django/commit/3b221caefc151f7750a322e18798c22343daba6f > I'm not aware of anywhere that it is being used; I'm guessing it exists for historical reasons, but I have no idea what those are. If the tests still pass when you've removed this code, I see no reason to keep it around. > 4. I've renamed DatabaseValidation.validate_field to check_field and > changed its > arguments. They were: `errors` -- ModelErrorCollection [7], `opts` -- meta > of > the model of the field and `f` -- the field; The method returned None. Now > there > is only `field` argument and the method returns list of errors. It's not > public > API, but we should go through deprecation process. > > How can we do that regarding changed arguments? We can call old > `validate_field` > method where the backend specific validation is triggered [8]. By default, > the > old method will call `check_field` method. The old one need to transform > list of > errors into strings and add them to `errors` list. The problem is that at > [8] we > need to convert the strings again to errors. That cannot be done in a > graceful > way. Is there any other way to achieve deprecation? > > I'd suggest that we ship both APIs -- validate_field() unmodified to support older codebases (but internally documented to indicate that we're moving away from that approach), and a new check_field() method that does things the New Way. As a migration aid, the default implementation of check_field() could invoke validate_field() and just convert the output into the new format -- it should be possible to retrieve all the required arguments from the data you already have
