Adding "SITE_ID = 1" to your settings will get you past the exception
without having to add it to INSTALLED_APPS. I had to do this one of my
projects.
On Aug 21, 7:02 pm, Vladimir Prudnikov wrote:
> Yep, django.contrib.sites is not included in the INSTALLED_APPS list.
>
> On 21 Aug 2009, at 10:4
line of code to allow middleware
exception handling.
#12250 http://code.djangoproject.com/ticket/12250
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
Scanned all the 6000 tickets for "exception" and found it (#6094).
Didn't find that when I searched before creating the ticket.
--
Michael Manfre
On Dec 9, 11:22 pm, Alex Gaynor wrote:
> On Wed, Dec 9, 2009 at 11:21 PM, Michael Manfre wrote:
> > If a middleware throws
With multiple database defined, what is the expected behavior for
syncdb and the other db related commands? The documentation shows that
it is relatively easy to associate an admin form with a given
database, but is there a way of associated a model or app to a given
database?
Regards,
Michael
sed with a "mssql
isn't officially supported by Django" comment.
If you review one of these tickets, please keep my goal in the back of your
mind. I welcome feedback on better ways of approaching my proposed changes.
Regards,
Michael Manfre
--
You received this message because you are
Thanks for the heads up. I'm getting very close to having the test suite
pass. After I accomplish that goal and establish a more solid reference
point for django-mssql, I'll look in to the work you've done with adodbapi.
Regards,
Michael Manfre
On Thursday, May 17, 2012 10
to switch to another backend where the
maintainer follows a different set of "best practices". There are many ways
of storing the same data that are all completely valid. The most likely
problem field will be IPAddressField due to varchar(15) vs. unsigned int.
Regards,
Michael Manfre
--
very python project that I run
on windows has PIL or pywin32 as a dependency, which requires me to
remember to add "--system-site-packages", else it breaks (and not always in
a way that is detected immediately).
--
Michael Manfre
--
You received this message because you are subscr
re/django-mssql/src/eff1ed275fdd/sqlserver_ado/compiler.py
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/
y query with aggregates or
slicing.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/cKMiQzb3-04J.
To post
On Mon, Jul 30, 2012 at 9:32 AM, Gijs Molenaar wrote:
>
> Hi Michael,
>
> Op dinsdag 10 juli 2012 17:51:16 UTC+2 schreef Michael Manfre het volgende:
>>
>>
>> On Monday, July 9, 2012 11:25:47 AM UTC-4, Gijs Molenaar wrote:
>>>
>>>
>>> T
on?
>
> Thanks!
>
> - Gijs
>
I vaguely remember encountering a problem with forward references when I
was adding support to django-mssql for Django 1.4. Can you post the
traceback? It might jog my memory.
--
Michael Manfre
--
You received this message because you are subscribed
rmine what to do if more than one is returned when they
only expected
a single result. Having all of the conflicts is a lot more useful than the
"returned more than
1" exception.
Regards,
Michael Manfre
On Wednesday, September 19, 2012 6:41:25 PM UTC-4, Anssi Kääriäinen wrote:
>
jango-mssql's compiler, I need a clear
way of identifying when the query is a sub-query. If this is not a safe way
of using with_col_aliases, is there another?
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers"
aggy UI. It
might have been better if I was able to get a folder mapped so I could use
an editor on the host Windows system, but I deleted the VM prior to
devoting enough time to figure that out.
Regards,
Michael Manfre
On Saturday, December 22, 2012 7:28:39 PM UTC-5, Kevin Veroneau wrote:
&g
It's a huge
body of work for an small edge case. The arguments also seem to provide a
strong justification for revisiting the idea of moving database backends
out of the core. I don't want to sidetrack this thread, I'll start a new
thread momentarily, but I think the idea is relevant for
and move code
- Abstract out any backend specific code in the ORM by extending the
database API
- Move backend specific tests to appropriate project
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To u
On Tuesday, March 5, 2013 3:31:59 PM UTC-5, Florian Apolloner wrote:
>
> Hi,
>
> While I agree that moving database adapters out of core has some merit, I
> don't think that having sqlite as a reference implementation is a good
> idea: For one some features are somewhat hacky in sqlite (and peo
On Tuesday, March 5, 2013 5:01:01 PM UTC-5, Florian Apolloner wrote:
>
> Hi Shai,
>
> On Tuesday, March 5, 2013 10:32:29 PM UTC+1, Shai Berger wrote:
>>
>> In recent years, I have been the main contributor to South's MSSQL and
>> Oracle
>> backends. I am biased towards having MSSQL treated as a
Hi Andre,
On Tuesday, March 5, 2013 5:39:29 PM UTC-5, Andre Terra wrote:
>
> If I may weigh in on the matter as an outsider, if we consider "The Django
> Project" as a "business", insofar as it aims to have as many users and be
> as ubiquitous as possible, there's considerable value in having MS
On Wed, Mar 6, 2013 at 12:47 PM, Florian Apolloner wrote:
> On Wednesday, March 6, 2013 3:32:45 PM UTC+1, Michael Manfre wrote:
>>
>> The lack of data validation is definitely a nogo for production sites,
>> but imo sqlite in production is also a nogo.
>>
>
> Righ
ng compatible with new Django versions or whatever. If it's really
> not important enough to anyone that it can stay modern outside of core,
> then it will die, but we should make it a trivial matter to fork and adopt
> for whoever needs it.
>
This approach sounds a lot bette
ea I had in mind for backends while I was typing up
this proposal. You articulated it better than I did. A main problem I now
see with it is if the ownership of a bug cannot be mutually agreed upon
between Django and the extension, then this could cause doubt about what it
really means to be "off
> Linux machine too, it would also make testing easier since we'd just need a
> VBox with MSSQL ;) Supporting a commercially available product but
> requiring to run even more commercial software seems like counter intuitive
> to me.
>
Django needs a VBox running Windows for testing, r
> will let you read it from Python.
>
>
> nice.
>
> does the client run on non-win32 plaforms? from a cursory read of the
> website, adodbapi seems to require pywin32.
>
adodbapi is included with pywin32 and requires it.
Regards,
Michael Manfre
--
You received this m
save
every other backend from having to potentially jump
through unnecessary hoops (mangling more SQL).
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receivin
ing limit offset is with nested selects.
Maybe someday the non-standard LIMIT/OFFSET keywords will get added to the
standard (I truly hope this happens) so Oracle, MSSQL, DB2, and Informix
could share SQL with postgres and mysql without needing to mangle it.
Regards,
Michael Manfre
--
You received
the standard to deal with OFFSET,
which is usually the more painful part of the problem. Window functions
were added in the 2003 standard, but they can have some issues with
ordering and I don't think the standard requires a way of being able to
filter by some sort of result row number.
Regar
the other database with Django backends seems to show that
all of them have a beta or stable release with support for a simple
limit/offset syntax, with many supporting the standard defined syntax. This
might make the generic approach as simple as adding an
DatabaseOperatoins.limit_offset_sql() abstrac
few different models with staff defined
URLs. The traditional Http404 middleware pattern was a bit repetitive and I
solved the problem with this middleware (
https://gist.github.com/manfre/5262782). The heart of the middlware is
ContentMiddleware._process(), which contains the "was this handle
urls, but it would be a bit ugly and less
flexible with cache timeouts.
Regards,
Michael Manfre
--
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 dj
should be possible, but would
be complex and require maintaining additional state information on the
DatabaseWrapper and connection to allow all the various places to figure
out what it should be doing. I do this in a very limited way for
django-mssql to allow for newer features in SQL Server 200
+1 to a saner repr(request) and not having to type "HTTP_". What sort of
deprecation cycle are you thinking for this?
Regards,
Michael Manfre
On Mon, Apr 8, 2013 at 4:02 PM, Luke Plant wrote:
> Hi all,
>
> This is already the subject of a ticket, but I didn't get a r
.com/en/dev/topics/logging/>
appropriately."
-
The core already provides a nice way for any app/project to log the 404's
however they desire.
Regards,
Michael Manfre
On Thu, Apr 11, 2013 at 3:09 PM, Babatunde Akinyanmi
wrote:
> Hi Javier, why no
>
> Sent from my Windows Pho
en Django adds UUIDField to the core field types, each backend can
define the appropriate column type (BINARY(16), CHAR(32), uuid,
UNIQUEIDENTIFIER, etc).
[1]
https://github.com/dcramer/django-uuidfield/blob/master/uuidfield/fields.py
Regards,
Michael Manfre
--
You received this message b
ing a filter from
"Older than 6 months" to "Older than 1 month" without having to select
"All" in between. The options could be hidden with CSS to match the
proposed behavior.
Regards,
Michael Manfre
On Thu, Apr 18, 2013 at 1:19 PM, Przemysław Suliga wrote:
&g
On Thu, Apr 18, 2013 at 2:25 PM, Przemysław Suliga wrote:
>
>
> On Thursday, April 18, 2013 7:59:59 PM UTC+2, Michael Manfre wrote:
>>
>> - What should happen if not all of the filters on a ModelAdmin support
>> being incremental? Exception, allow some filters to yiel
ve an explanation as to why the case is being closed.
Regards,
Michael Manfre
On Mon, May 13, 2013 at 12:06 PM, AK wrote:
> On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote:
> > On Mon, May 13, 2013 at 2:12 AM, Chris Wilson
> > wrote:
> >> The status WONTFIX sounds awf
same
disparity that 3rd party database backends faced, what are your thoughts on
having the jinga2 engine maintained outside of core? This would leave only
the string template reference implementation and the DTL in the core.
Regards,
Michael Manfre
On Sat, Nov 1, 2014 at 6:30 PM, Aymeric Aug
Should the unicode validated field (either options) have a different
internal type for the sake of 3rd party database backends? I'm not sure if
any currently store SlugFIeld in an ascii char datatype and would need an
easy way to differentiate.
Regards,
Michael Manfre
On Tue, Nov 4, 2014 at
like an option to SlugField and I feel
> UnicodeSlugField is a bit ugly. If however we find an example where
> Michael's point is valid (an external 3rd party backend which uses ascii
> chars for SlugField now) then we should go with that.
>
> On 5 November 2014 03:20, Michael Ma
On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger wrote:
> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> > We can change the internal type of SlugField for option 1 based upon
> > whether or not the field should be unicode. Whether or not an existing
> > backend s
Overriding get_db_prep_lookup seems like it would cause problems. Even if
were only registered when Oracle is in use, that would make multi-db with
Oracle as one of the backends problematic.
On Sat, Nov 15, 2014 at 5:46 PM, Josh Smeaton
wrote:
> Clever. I don't mind this approach at all. Will th
improvements, backwards incompatible changes are not likely to
happen. There is a huge cost involved with forcing everyone to update their
templates. Ideas on improvements that are backwards compatible would be
welcomed by many!
Regards,
Michael Manfre
On Mon, Nov 17, 2014 at 9:17 PM, wrote:
> He
needed when using the Admin. E.g. write custom ModelAdmins or
admin filters that restrict the resultset size.
I don't think Django should automatically limit these queries.
Regards,
Michael Manfre
On Tue, Nov 18, 2014 at 7:58 AM, Rick van Hattem wrote:
> Hi guys,
>
> As it is right
On Tue, Nov 18, 2014 at 7:42 PM, Josh Smeaton
wrote:
> To me, "sane default" means django should not silently alter the query to
> provide a LIMIT when it is not asked for.
>
> I have also run into situations where doing a .count() or iterating a full
> table has broken the application, or put to
g it along to the parent.
I think it's safe to say that this functionality is unlikely to find its
way in to Django, but if you have questions about the custom database
backend approach, feel free to contact me.
Regards,
Michael Manfre
--
You received this message because you are subscribed t
Requiring fewer moving parts for small sites is definitely an improvement.
+1 to Collin's plan.
Regards,
Michael Manfre
On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer wrote:
> I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of
> sense.
>
>
usage, e.g.
URLs, but there is no reason to enforce this requirement in all uses of the
data because not everyone will expose a UUID in a URL.
-1 from me.
Regards,
Michael Manfre
On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz wrote:
> Hi, I am glad to see the UUID field coming to 1.8
>
>
LTS?
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegro
Please open a ticket for this.
On Fri, Dec 12, 2014 at 9:11 AM, Bruno Ribeiro da Silva <
bruno.dev...@gmail.com> wrote:
> Hey everyone,
>
> I just found out that the new schemes option of URLValidator causes
> incompatible changes for people who were using custom regex to restrict
> schemes. Coul
is if you wanted to support multiple active sessions using
different authentication backends for the same user object.
Regards,
Michael Manfre
On Sat, Dec 13, 2014 at 4:28 AM, Roman Akopov wrote:
>
> Tim,
>
> It's not about the benefit, it's about the possibility. The one
+1 for lists.
On Wed, Dec 17, 2014 at 3:54 PM, Carl Meyer wrote:
>
> On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> > I’m about to introduce a new setting that is a sequence of things,
> TEMPLATES, and I have to decide whether it will be a tuple of a list.
> >
> > Unfortunately Django is very
tensely as live sites?
Regards,
Michael Manfre
On Sat, Dec 27, 2014 at 5:59 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> My twelfth update is online:
> https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>
> It com
Thanks for the explanation. It makes sense to remove select_template.
Regards,
Michael Manfre
On Sun, Dec 28, 2014 at 3:53 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hi Michael,
>
> > On 28 déc. 2014, at 07:12, Michael Manfre wrote:
> >
>
+1 to delaying the freeze to get this feature fully in place, especially
since 1.8 will be an LTS release. Is there precedent to doing a freeze with
an exemption for an in progress feature? If so, that is another option to
an outright extension.
Regards,
Michael Manfre
On Sat, Jan 3, 2015 at 8
For completeness, I'm Michael Manfre and have been the maintainer of
Django-mssql [1] for the last 6+ years. Future releases of Django-mssql
will officially support a single version of Django. Support for legacy
versions of Django will be maintained if it requires little effort.
Work on D
The situation you described was definitely a learning experience for your
company. Your strong opinion in favor of tuples is also noted.
For the various reasons stated in this thread, I'm still +1 for lists.
Regards,
Michael Manfre
On Mon, Jan 19, 2015 at 3:13 PM, Andreas Kahnert wrote:
test
suite, but that is something that should probably happen regardless of
parallelization.
I'm imagining database backends being able to control whether or not they
support parallelization and if each process needs its own database.
Regards,
Michael Manfre
On Fri, Feb 6, 2015 at 11:05 A
It's reasonable to support backend specific aggregate functions. The
database backend API contains
BaseDatabaseOperations.check_expression_support for this exact reason. Feel
free to create the ticket.
Regards,
Michael Manfre
On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
better than
having the extra complexity of using stored procedures in a Django project.
Regards,
Michael Manfre
On Fri, Feb 27, 2015 at 2:46 PM, Tom Evans wrote:
> On Fri, Feb 27, 2015 at 3:19 PM, aRkadeFR wrote:
> > What do you mean by a single roundtrip?
>
> He means aski
As the others have already stated, patience is required if you want
meaningful feedback.
Have you thought about how CompositeFields and SubFields will interact with
migrations?
Regards,
Michael Manfre
On Wed, Mar 4, 2015 at 8:16 AM, Thomas Stephenson wrote:
> Considering the past
ybePoint(...):
>has_point = models.BooleanField()
>point = Point()
>
> because of the inheritance limitations (which I might have to lift in the
> medium-long term anyway, but which I'd like to preserve for as long as
> possible to keep the initial implementation and API
-1 on silently changing the field definition. At best this would result in
an unnecessary migration when the error is discovered. Django should error
out with a message that the composite field definition is invalid.
Regards,
Michael Manfre
On Sun, Mar 8, 2015 at 12:29 PM, Thomas Stephenson
uses to write
the model data.
Regards,
Michael Manfre
On Tue, Mar 10, 2015 at 11:56 AM, Collin Anderson
wrote:
> Hi All,
>
> We recently added database introspection of defaults for purposes of
> testing migrations.
>
>
> https://github.com
On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner wrote:
> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
>
#x27;s useful being able to modify the models that ship with Django.
E.g. increasing the size of user name field.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubs
I like the alias.
On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> `python -m django` as a alias for `django-admin` sounds good.
>
> --
> Aymeric.
>
>
>
> On 30 avr. 2015, at 19:15, Ryan Hiebert wrote:
>
> https://github.com/django/django/pull/4588
this issue.
Regards,
Michael Manfre
On Tue, May 5, 2015 at 8:52 PM, Paulo Maciel
wrote:
> I am returning the query Something.objects.all().order_by(Lower('name'))
> but the order is not respecting names that start with accent, causing these
> results appear at the end of
on
the post. The topic of batch deletion signaling has come up before, but I
don't remember the outcome (or whether it was on here or IRC). I'll try to
find it and report back when I get to a more capable device.
Regards,
Michael Manfre
On Thu, May 7, 2015 at 7:36 PM, Antoine Cat
This group is for the discussion of developing the Django framework.
Discussions and questions related to using Django should take place on the
django-users group.
Regards,
Michael Manfre
On Mon, Jun 1, 2015, 7:11 AM Swapnil Bhadade
wrote:
> Which are Django packages for full stack developm
I like Colin's proposed schedule.
Regards,
Michael Manfre
On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen
wrote:
> +1 to Collin's release schedule.
>
> This schedule should make it extremely easy to support "develop using
> latest release, maintain using latest LT
I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9
to 2.0 to line the versions up with the new paradigm without the X.1 LTS
oddball.
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson
wrote:
> I also like the gdoc as it is. (1.8 LTS,
, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On
27;t support it.
Regards,
Michael Manfre
On Tue, Jul 7, 2015 at 9:57 AM, wrote:
>
> Hi all,
>
> I'd like to know why this feature will be only available on postgres and
> not as a Field for any database, like this product? This Field would be
> very usefull for many users I th
On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron
wrote:
> Hi Loic,
>
> Agree with having a db_default kwarg.
>
> I am not using multiple databases so no experiance with db routers. So how
> would should we handle routing between different databases when the
> db_default value is not compatible wi
As some one who has had to abuse .extra() at times to make mssql things
work, I support this approach.
On Fri, Jul 31, 2015 at 4:00 PM, Tim Graham wrote:
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some
On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron
wrote:
>
> > - Do we want to allow extending this to defaults that are applied on
> every save (automatic database backed modified timestamps for example)?
>
> +1 for this one too.
>
This behavior would be a nice step toward computed (readonly) dat
+1 for making it doable for 3rd party apps.
Regards,
Michael Manfre
On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen
wrote:
> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> differ
I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain
I agree with Shai. The database backend needs to be able to control this
feature.
Regards,
Michael Manfre
On Sun, Sep 6, 2015 at 12:48 PM, Shai Berger wrote:
> Hi,
>
> On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote:
> >
> > This will require ./runtest
stgresql specific field should exist in
django.contrib.postgres.
Regards,
Michael Manfre
On Tue, Sep 22, 2015 at 8:40 AM, Collin Anderson
wrote:
> If anyone's curious, the mysql situation is as crazy as you might expect.
> :)
>
> The max is only determined only by the total row size
ssuming no core
devs chime in with a -1, I'd say create a ticket and you and/or others can
start working on a pull request.
Regards,
Michael Manfre
On Sun, Oct 11, 2015 at 5:00 AM, John Michael Lafayette <
johnmichaelreed...@gmail.com> wrote:
> Python now has static type c
e work. Regardless of the decision,
the repo will be hosted on github.
Regards,
Michael Manfre
--
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)&quo
On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>
>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>> This may follow the current pattern Aymeric
drop support for all Django versions before the
> LTS, check their package with the LTS using python -Wall and make the
> deprecation warning fixes, then seamlessly add support for the next version
> of Django.
>
> Does that make sense?
>
This makes sense to me. +1
Regards,
M
#x27;, 'FAST 10')
and have it set
Query.query_hints = ['HASH GROUP', 'FAST 10']
I'm currently patching in support so I can do something like this for
django-mssql.
Regards,
Michael Manfre
On Jul 22, 12:03 am, Russell Keith-Magee
wrote:
> On Fri, Jul 16, 2
namespaces
that are defined simply by a backend willing to look for the specific
name. If not, there would need to be discussion about which namespaces
are defined by the core and how unsupported backends would register
new namespaces.
Regards,
Michael Manfre
--
You received this message
://code.djangoproject.com/ticket/14299
--
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developer
27;]
> If I'm thinking correctly, with an additional method like
> 'filter_settings', it might be possible to have a default
> ExceptionReporterFilter that does the filtering of settings that is
> currently hardcoded into django/views/debug.py.
You're correct.
On Jun 2, 3:33 pm, Luke Plant wrote:
> On 02/06/11 19:45, Michael Manfre wrote:
> > On Jun 1, 5:53 am, Luke Plant wrote:
> >> Would it possible to make the sensitive decorator add some kind of
> >> strategy object to the request, which itself is responsible for the
Ticket #15829 (https://code.djangoproject.com/ticket/15829) includes a
patch that allows exposing the item object the template, which is all
that is needed to support any of the specific sitemap extensions.
Regards,
Michael Manfre
On Jun 22, 8:05 pm, Jeremy Dunck wrote:
> Referring to Djang
I reviewed:
#16358
#16355
#16359
#16353
#16316
Please look at #15829 (https://code.djangoproject.com/ticket/15829).
Thanks,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
I opened ticket #12250 for this exact reason a while ago. It's
currently design decision needed. I'm still in favor of giving
middleware a chance to handle errors raised by middleware.
https://code.djangoproject.com/ticket/12250
Regards,
Michael
On Sep 1, 11:48 am, Tom Evans wrote:
> Hi all
>
>
ty backend support in general: My opinion is that we should
> include them all in core. The rules would be:
>
By "them", do you mean 3rd party backend tests or the entire 3rd party
backend?
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Googl
eature
checking in the backend, and more eyes watching commits (even if no one
else works on the backend). There is also the potential of easily fixing
the poorly named flags on DatabaseFeature.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
&qu
or everyone
to consistently adhere to the same style without enforcement. Trying to
enforce guidelines would be more futile than trying to keep people from
posting django-users questions here.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
&quo
a clean rewrite in PHP.
Regards,
Michael Manfre
On Tue, Jul 2, 2013 at 2:33 PM, Wim Feijen wrote:
> Hi all,
>
> Many people post django-users questions to this group by accident. I find
> the name of our group to be misleading: it seems to refer to people who
> develop in djang
Has anyone thought to contact HostGator and see how they would react to
Django dropping FastCGI and/or whether they would be willing to support a
WSGI option.
Regards,
Michael Manfre
On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:
>
> On
for all columns.
Regards,
Michael Manfre
On Wed, Jul 31, 2013 at 2:58 PM, Richard Laager wrote:
> On Wed, 2013-07-31 at 13:01 +0100, Simon Riggs wrote:
> > 3) retrieve via DESC, apply LIMIT and then re-sort by ASC using derived
> table
> ...
> > (3) would require two sorts
1 - 100 of 202 matches
Mail list logo
