Sadly, it cannot be used out of the box, partial objects don't work
with dispatcher and some unit test failed when I tried to use it in
models.base. But it could be integrated slowly.
On 25 дек, 01:17, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> I suggest using python 2.5 st
from keywords attribute. So they still can be
inspected but in different way. The cost of speed.
On 25 дек, 02:34, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On Dec 24, 2007 4:17 PM, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I suggest
I use custom cache backend with Django and I want to share it with
community. The code is very simple:
http://www.pastethat.com/aNWVB
The main advantage is that it is persistent just like 'db' backend and
in the same time uses memory which you can fine-tune with cache_size
parameter. I believe th
I understand your point. Durus cache just works for me extremely well.
It has all the advantages of both file and database backends coming
with Django plus the memory-based pythonic cache. Of course I could
live without it. But since I wrote it I don't see any reason to not
use it.
The only bad t
... continued from Cache backend thread.
I have a lot of working code that I know will never get into Django
and I just can't publish it as an external project/projects because
it modifes the core of Django dramatically. For example, I use
Firebird database. I want to use native '?' placeholders
eTextField type, allow the
optional max_length for TextField and allow backends to change
django.core.management.sql and customize filed validation I can
publish my work as external Django database backend.
On 26 дек, 14:58, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-12
Django documentation states that "For performance, (uploaded) files
are not stored in the database" Is this really true? Research
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
shows that it's more advantageous to store small media files (<256K)
in the database, esp
Thank you. Now I have better understanding. I agree that I was too
pessimistic and maybe had some wrong assumptions about this stuff. I
didn't say that Django is not production-oriented I only mean that
it's hard to extend Django with alternative database keeping the same
production quality level.
The main problem is that I already have a working code that does all
that I have written about and a lot more. Trying to fit it to external
Django extension will take too much time and effort. So I find that it
would be better to start a new independent project based on Django.
The main advantage
The subject of this thread is not a question. I just try to highlight
the difficulties of third-party module creation. It's not so easy as
suggested in
http://www.pointy-stick.com/blog/2007/11/11/django-tip-external-database-backends/
--~--~-~--~~~---~--~~
You re
Updated the patch http://code.djangoproject.com/ticket/6214
Another small optimization.
1. It passes all unit tests
2. It is IMO more clear
3. It is faster (1-1.5 seconds per 1 models on my machine) than
current django model creation
--~--~-~--~~~---~--~~
You r
Piotr, I already answered you at Django users, here are some other
points.
Sometime you may not need 1-to-1 translations, e.g. each language may
have its own independent set of articles. Some parts of the site may
exist only in one language. And for some people, like me, it's easier
to deal with
No! Unicode usernames is a bad idea. Usernames can be used for URLs,
paths and other technical stuff. Unicode usernames is a source of
unlimited potential bugs. It might be a good idea to add the unicode
'nickname' field that can be used instead of username in views - and
still use 'username' for
There are a lot of good reasons to have username ascii-only
1. You may want to login to your site from non-national keyboard/OS
2. URLs with unicode characters look ugly
3. Paths and filenames may be broken
4. It's not hard to transliterate your real name with ascii-only
letters
--~--~-~--
> kwargs = dict([(cls._meta.fields[i].attname, v) for (i, v) in
> enumerate(args)])
>
> Seems like any code which explicitly needs to handle tuple
> instantiation (likely the minority) can supply a helper method using
> something similar to the above.
Yes, but why not have fromtuple classmethod
> One of the other things planned as part of qs-rf is the ability to use
> custom queries to initialize models -- something like
> ``Model.objects.custom_query("SELECT ...")``
That's not enough - I need this feature to initialize models from the
result of stored procedures, not just simple queries
If you depricate this functionality please provide an alternative like
Model.fromargs() classmethod. It is extremely useful when you need to
create Model objects from custom queries. Like here:
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/custom_methods/models.py
in Article.
Ok I really can use Model.objects.custom_query("EXECUTE
PROCEDURE ...") but someone may need more options.
On 29 янв, 23:50, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> > One of the other things planned as part of qs-rf is the ability to use
> > custom queries to in
I agree that positional arguments instantiation is confusing and
mixing it with keyword instantiation is even more confusing - it would
be great if default Model.__init__ will be keyword argument only. But
I think we still need a faster alternative. Comment in Model.__init__
states that 'nstantiat
Speed:
>>> t1.timeit() # Model.__init__ from django trunk with args stuff stripped
179.84739959966981
>>> t2.timeit()
139.67626695571641 # Model.fromargs()
Implementation:
def fromtuple(cls, values):
dispatcher.send(signal=signals.pre_init, sender=cls,
args=values, kwargs={})
new_
> I'm pretty strongly opposed to a fromtuple (or whatever) method: it's
> brittle and to tightly couples code to the arbitrary order of defined
> fields.
Jacob, why are you opposed to alternative instantiation methods?
Standard Python does it with dict.fromkeys() Why not?
--~--~-~--~~-
o the nature of Python.
import this
...
Although practicality beats purity.
...
On 30 янв, 02:57, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On 1/29/08, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > Jacob, why are you opposed to alternative instant
http://pastebin.com/m62466a6b
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send ema
Yes, they look the same and here they are if anyone is curious:
>>> 'ETOPAHKXCBMeopaxc' == 'ЕТОРАНКХСВМеорахс'
False
>>> 'ETOPAHKXCBMeopaxc'
'ETOPAHKXCBMeopaxc'
>>> 'ЕТОРАНКХСВМеорахс'
'\xd0\x95\xd0\xa2\xd0\x9e\xd0\xa0\xd0\x90\xd0\x9d\xd0\x9a
\xd0\xa5\xd0\xa1\xd0\x92\xd0\x9c\xd0\xb5\xd0\xbe
\xd1\x
> I understand this may be a corner case, but the ability to extend
> Django's initialization is really nice, and this optimization makes the
> code ugly on the applications side (and was there really a need for an
> optimization ? "1-1.5s per 1 models" does not tell much on what has
> been ga
check() belong to the database backend? Most of the
Field checks are backend-specific and I have a strong need to do this
in my custom db backend.
Ivan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develop
keep it in mind.
>
Thank you. Hope to see this soon in qs-rf :). I am forced to use some
ugly hackish
things to check for those TTCGW - this feature will make the life of
all Django backend
developers brighter.
Ivan
--~--~-~--~~~---~--~~
You received this messag
Malcolm Tredinnick wrote:
>
> On Fri, 2008-03-07 at 21:03 -0800, Ken Arnold wrote:
>> I just hacked together http://www.djangosnippets.org/snippets/631/
>> which includes the technical_500 error view page with the admin error
>> email. I did this after seeing a Django site have lots of small erro
Mike Axiak wrote:
> 1. Leave forms code alone, causing (a) DeprecationWarnings and (b)
> the files to be read into memory when saving.
> 2. Modify the form code to access the attributes of the
> UploadedFile, but on AttributeError use the old dict-style interface
> and emit a DeprecationWarning.
Why the developers don't check for duplicate tickets?
--
Ivan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers
nally or allege unfairness; in all likelihood, it was just a
> mix-up that happened in the clamor of the sprint.
Thank you for explanation. Now I see that it's all about sprint. But
it's still feels very bad when you see some other patch merged when
you have the same thing (even that s
s
handled by __import__ - I checked and tested this when created my
patch.
--
Ivan Illarionov
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
Just changed the subject.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email t
7;
before passing it to database, thanks to the type_conv_in/
type_conv_out functionality in kinterbasdb package.
I think that it's perfectly OK to distribute a patch to change the
hardcoded functionality -- it's far better than trying to monkey-patch
the code under active development.
> I have a patch in my backend already, to enable regex searches in MS
> SQL. I think this is reasonable, as you have to install either a COM
> or CLR extended stored procedure in your database to get this
> functionality. Inserting values in a DateTimeField is perhaps a bit
> more basic a functio
Mike Axiak wrote:
> I didn't want to use the extra setting either, but I finally caved in
> after working with it (and discussing with Ivan). I will certainly
> explore any other possibilities.
My original reason for settings was that a single upload handler can't
possibly kn
Malcolm Tredinnick wrote:
> Then those people deserve to be beaten heavily about the head and
> shoulders. S3 is NOT a reliable upload endpoint. They (Amazon) say
> there'll be approximately a 1% failure rate for attempted uploads. As 37
> signals have noted in the past (they use it for their whit
Ivan Sagalaev wrote:
> Nobody stops a developer from doing both things in parallel: storing on
> disk and streaming to S3.
> they will gain heavily from not doing writes and
> reads of the whole file on local disk.
Looks like I'm contradicting myself a bit here :-). But it
Malcolm Tredinnick wrote:
> If you only want a unique object, make sure that
> the arguments you provide as the defaults argument specify it must be
> unique at the database level.
BTW, may be get_or_create should be rewritten as:
get()
try:
create()
except BackendSpecifi
Malcolm Tredinnick wrote:
> That's more or less how it is written, since r7289 (March 18).
Great! We've been running too long on a snapshot from December then :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dja
Rob Hudson wrote:
> * Defaulting to "[-\w+]" makes sense to me as a default regular
> expression to catch most URL patterns. It can catch strings, slugs,
> and numbers. Things like this would still work: "/{{ year }}/{{ month
> }}/{{ day }}/{{ slug }}/" but may not be as optimized as specificall
Travis Parker wrote:
> I was just recently optimizing database usage in a django app and
> found myself managing these things myself (sorted(qs) instead of
> qs.order_by(), filter(filterer, qs) instead of qs.filter()) because I
> didn't want the database to get hit again when modifying already-use
I bet Oracle is broken in qs-rf.
Hope this helps.
Regards,
Ivan Illarionov
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@goog
Hello everyone (and especially Malcolm :-) )
I've just hit a wall with a behavior that I find a bit strange. When a
model is instantiated from a queryset result it's not created with it's
own constructor but instead uses Model.from_sequence that does creates
an Empty() instance and then change
Martin Diers wrote:
> I could be wrong, but I believe that this is because a Model is not
> derived from the default __metaclass__, but is generated by a separate
> class factory which overrides the default behavior.
Yes, but my question is not how it's happening but what's the reason of it.
David Cramer wrote:
> When an api is limited how would you propose to extend it? You do it the way
> OO is built.
> When releases happen you can expect things to break. When they don't how do
> you expect to
> know when you are safe to update?
From this point of view it's never "safe" to upd
Hello! I'll try to answer as much as I can.
Jean-François wrote:
> - can Django run in a cluster environnement (OpenVMS has a "shared
> everything" cluster design) , meaning running simultaneous Django
> server on different systems, so in different processes, or it is
> mandatory to run in a one-
Jean-François wrote:
> My question was not really specific to any database backend (aggree
> that probably all database system, including Rdb can start a
> transaction implicitly, inclugind Rdb). But as I have noticed that a
> method start_transaction_sql() exist I have expect that this method
> w
Jean-François wrote:
> Oops... I haven't thought to trace connect/disconnect operation to the
> database only commit/rollback.
> Now, I have a better understanding of the underlaying model. I suspect
> that open a database connection then closing it for each request may
> be a fairly expensive ope
Earlier versions of Firebird (1.5) don't work with model inheritance
and queries like filter(...).filter(...) and few others while Firebird
2.0 works.
And, remember, Firebird backend is ALPHA software. It's not for
production yet.
Regards,
Ivan
On May 6, 1:23 am, "Rahein Sorite" <
Rahein,
Please email me directly with questions about Firebird backend in
Django because I am the only maintainer of this project and this group
is a wrong place to post such questions.
I can send you the patched tarball if you need it.
--
Ivan
[EMAIL PROTECTED]
On May 8, 6:48 pm, Rahein
Simon Willison wrote:
> {{ article.something.title }} - outputs text if article is there,
> fails silently otherwise
>
> Which leaves us in a tricky situation. A global settings.py variable
> for "throw errors on missing template variables" is a bad idea as it
> kills application portability
It
Simon Willison wrote:
> Thankfully Ivan Sagalaev's confusingly named mysql_cluster
BTW does anyone have a suggestion how to rename it? I've picked
mysql_cluster simply because I didn't know that there exists the thing
named "MyS
Simon Willison wrote:
> How about mysql_masterslave or mysql_replicated (I prefer the second)?
Yes, mysql_replicated seems right. Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
They're supplied by the developer (code writere), so they
> should be treated as safe strings. Please open a ticket for this and
> we'll fix it.
There's already a ticket opened:
http://code.djangoproject.com/ticket/9111
Originally this was fixing only the escape of form errors, but
list twice, I think I got caught in the spam
check)
--
Giuliani Vito, Ivan
http://zeta-puppis.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
ct.com/en/2.1/ref/utils/#module-django.utils.http
but not a single mention of is_safe_url...
Ivan.
On Wednesday, October 10, 2018 at 1:06:46 PM UTC+3, Markus Holtermann wrote:
>
> Hi all,
>
> Django provides a function `django.utils.is_safe_url()` to ensure that a
> given URL (a
me options in settings.py automatically
(copy-pasting settings is about as bad as looking up packages) but honestly
I'm used to having to rewrite settings all the time and don't know much
about available built-in automaton.
Ivan.
On Fri, 28 Jun 2019, 04:30 Josh Smeaton, wrote:
>
Not closely related, but what about composite keys? I think having such an
implicit arg interpretation would make it much more complicated to use,
say, a combination of charfield and integerfield as your key (primary or
foreign doesn't matter): what does .get(('string', 123)) mean?
.get(string=123)
ut some of them might not for will in the current queryset
api.
Ivan.
On Thu, 1 Nov 2018, 19:41 Ivan Anishchuk, wrote:
> Not closely related, but what about composite keys? I think having such an
> implicit arg interpretation would make it much more complicated to use,
> say, a combinati
Yeah, it can be pretty useful at times, for example, in api clients. I used
it quite a few times and had no idea it's not a part of the public api.
Ivan.
On Sun, Oct 28, 2018 at 12:29 PM Adam Johnson wrote:
> I needed that functionality on another project that doesn't use Dja
e something simple and effective for
when you prefer to use the default classes wherever possible.
Ivan.
On Sun, Oct 21, 2018 at 10:48 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> The default widget is fine for configuration tables with no mo
you ever
release any code, feel free to ping me for review or testing, chances are I
like your library and won't have to implement mine :) I have too many
library ideas and not enough time to work on them all, collaboration could
be much more better.
Ivan.
On Wed, Dec 5, 2018 at 3:15 PM Sa
Yep, I'm definitely in favor of dropping 3.5 early and using all the nice
features extensively. Especially type annotations. All projects I work on
use 3.6 or later for quite some time now, whatever debian guys might feel
about stability.
Ivan.
On Wed, Jan 23, 2019 at 12:16 PM Josh Sm
g on their values and I would really like if there
was a simple standard way of tracking dirty fields and saving only them in
a reliable way. I'll be grateful if someone finally makes it happen.
Ivan.
On Tue, Jan 29, 2019 at 4:43 PM Patryk Zawadzki wrote:
> I feel conflicted here as I
er is a great way to keep issues detectable by
flake8/pylint to a minimum.
Ivan.
On Sat, Apr 13, 2019 at 6:35 PM Herman S wrote:
> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I recommen
renaming all your variables so that you don't have to think
about naming them? Must be even better for productivity.
Ivan.
On Wed, Apr 17, 2019 at 12:35 AM Josh Smeaton
wrote:
> Ivan, what you’re talking about is subjective code formatting, and lends
> itself to extreme bikeshedding
How about making one of the third-party packages an optional dependency?
Celery, for example, does that: you can just install celery[redis] without
having to figure out what other packages you need to enable redis support.
Ivan.
On Wed, Jun 19, 2019 at 6:44 AM Josh Smeaton wrote:
> There
very hard to provide
`django.core.cache.backend.redis.Redis Cache` that depends on django-redis
and is an alias for `django_redis.cache.RedisCache` -- it's basically the
way it works with DB backends, I don't see why it wouldn't be a good idea
for cache as well.
Ivan.
On Thu, Jun 20, 2019, 04:02 Josh S
501 - 569 of 569 matches
Mail list logo
