> To solve it I proposed[1] another strategy: delegate type conversion
> to the backend. Otherwise, I think we will end with too many backend
> flags.
+1
I maintain the external Firebird backend and I would also prefer this
solution.
Ivan I
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
Hi, Rahein,
The Firebird patch and backend is against latest Django trunk and
depends on the newest Django features, especially new QuerySet/Query
classes. Please note that there are known bugs with very complex ORM
queries. It's also important to use the latest Firebird (> 2.0).
Earlier
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@google
> 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
_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 also switched to queryset-refactor branch rescently -- it has some
really great im
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
ecked 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 django-developers@googlegroups.com
> There are people doing triage regularly to check for duplicates;
> however, there are a large number of tickets and this one -- as
> mentioned above -- happened during the development sprint when there
> was already a large amount of ticket activity. Try not to take it
> personally or allege
Hey, I've just found that ticket #6789 was merged into trunk while my
ticket #6654 that was filed a month earlier and does the same thing
was ignored.
My patch is still better because it removes INVALID_PROJECT_NAMES that
became unnecessary -- all those names will be detected by __import__.
Why
> Only one of the current field checks is backend specific, although I
> suspect there are some Oracle-specific checks that might be handy. Most
> of them are completely generic (e.g. DecimalField must have a max_length
> feature).
There are certainly some backend-specific "Things That Can Go
> (2) Put a method on each field (and Options and maybe Model if needed)
> called something like sanity_check() -- we shouldn't use validate() as
> that means something else at that level -- and call sanity_check()
> manually from management/validation.py.
Could this sanity_check() belong to
> 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
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
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
to 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
> 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?
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={})
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
> 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
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
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
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
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
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
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
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
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
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,
, 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-26 at 03:38 -0
... 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 '?'
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
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 standar
I suggest using python 2.5 standard library functools.partial when it
is available instead of django.utils.functional.curry. This functions
are technically the same with the exception that partial is written in
C and is about 2 times faster.
Just replace every:
from django.utils.functional
35 matches
Mail list logo
