ple in the link above.
If you need more fine-grained control, you can of course also attach config
instances to individual objects instead of packages.
So, what do you think?
Greetings,
Waldemar Kornewald
On Sunday, February 16, 2014 11:55:24 AM UTC+1, Aymeric Augustin wrote:
>
> Hi Schu
On Tue, May 10, 2011 at 11:29 PM, Patryk Zawadzki wrote:
> On Tue, May 10, 2011 at 9:40 PM, legutierr wrote:
>> Maybe it is inevitable that this kind of debate will crop up in any
>> discussion of django-nonrel or NoSQL, but I very much hope that the
>> philosophical debate does not detract from
On Thu, Apr 28, 2011 at 12:37 PM, Eric Florenzano wrote:
> On Apr 28, 2:36 am, "Jonas H." wrote:
>> For anyone who's interested, here's the complete diff of Django-nonrel
>> against Django 1.3:http://paste.pocoo.org/show/379546/
>
> Are you sure this diff is correct? From a quick look over that
. Does any core developer have time
to help with this project?
Thanks!
Bye,
Waldemar Kornewald
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/
--
You received this message because you are subscribed to the Google Groups
&q
On Mon, Mar 28, 2011 at 6:40 PM, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 11:22 AM, Waldemar Kornewald
> wrote:
>> I do agree that it's too complicated (esp., the forms) and I plan to
>> improve django-filetransfers in this regard. The biggest complexity
>
On Mon, Mar 28, 2011 at 5:05 PM, Jacob Kaplan-Moss wrote:
> On Sat, Mar 26, 2011 at 8:45 AM, Waldemar Kornewald
> wrote:
>> That's pretty much exactly what django-filetransfers tries to do on
>> the download side:
>> http://www.allbuttonspressed.com/projects/django-
On Sat, Mar 26, 2011 at 2:08 PM, Jacob Kaplan-Moss wrote:
> On Sat, Mar 26, 2011 at 6:31 AM, Graham Dumpleton
> wrote:
>> In short, it is all a mess and trying to provide support for it in one bit
>> of code is possibly asking a bit much.
>
> One possible solution would be to split the problem up
On Thursday, March 24, 2011 2:40:39 PM UTC+1, Kristaps Kūlis wrote:
>
> I wish to note that Nginx implements this feature differently than
> LigHTTPd and Apache2
> http://wiki.nginx.org/XSendfile ,
>
> Should django implementation consider that ?
>
> My proposal to implement would be:
> 1. HttpFil
Hi,
it's possible to manipulate the settings object in a thread-safe way. Here's
our dynamic site middleware:
https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djangotoolbox/sites/dynamicsite.py
https://bitbucket.org/wkornewald/djangotoolbox/src/535feb981c50/djangotoolbox/utils.py
A
On Thu, Dec 2, 2010 at 5:03 PM, Jonas H. wrote:
> On 12/01/2010 08:04 AM, Waldemar Kornewald wrote:
>>
>> In the end JOINs will be a rather complicated solution. I thought
>> that's why you wanted to extend the ORM directly to handle embedded
>> fields in a specia
On Nov 30, 9:34 pm, "Jonas H." wrote:
> Hello List!
>
> I'm working on queries on embedded objects for Django-nonrel (more
> precisely, djangotoolbox) that will use JOIN-like syntax.
>
> For this, I need to know how to distinguish
> .filter(spam__op=eggs, foo__op=bar)
> from
> .filter(spam__
Hi Mikhail,
On Sat, Oct 30, 2010 at 1:22 PM, Mikhail Korobov wrote:
> Hi Waldemar,
>
> The problem was really hard to understand for me because I was
> assuming you're trying to describe django.contrib.staticfiles flaw
> while you were describing the problem with third-party asset managers.
It s
Hi Yuri,
On Sat, Oct 30, 2010 at 1:22 PM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> So, we agreed, it's not a problem with django, it's problem with those
> 3rd-party apps.
Yes, exactly! That's why I wanted an official standard that all
3rd-party apps can follow.
> Perhaps, you can write emai
On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss wrote:
> There's no way I'm adding text like that to the staticfiles
> documentation. Not in a million years. It's confusing to me, and
> *I've* been following this discussion. Can you imagine how confusing
> that's going to be to people who *hav
Hi Carl,
On Fri, Oct 29, 2010 at 7:41 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 29, 3:05 am, Waldemar Kornewald wrote:
>> Just to clarify: We are in fact talking about two questions here:
>> 1. Do we need a standard for URL handling?
>>
>> This is the most
Hi Jacob,
On Fri, Oct 29, 2010 at 4:58 PM, Jacob Kaplan-Moss wrote:
> Hi Waldemar --
>
> Like a few in this thread, I'm really having trouble understanding
> exactly what you're proposing. I think the best thing, then, would be
> if you could write some code to do whatever it is you'd like.
>
> J
Hi Yuri,
On Fri, Oct 29, 2010 at 12:04 PM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
> wrote:
>> Hi Yuri,
>>
>> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com
>> wrote:
>>> Hi Wald
Hi Yuri,
On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
> wrote:
>> Hi Carl,
>>
>>> As I read it, your option 4 means putting URLs into CSS files that
>>> will not re
Hi Carl,
On Fri, Oct 29, 2010 at 5:18 AM, Carl Meyer wrote:
> Hi Waldemar,
>
> Thanks for putting so much thought into this issue, and outlining
> these options in detail. However, I am not convinced that this
> something Django core should be concerned with. I think we need to
> maintain a clear
On Thu, Oct 28, 2010 at 4:41 PM, Waldemar Kornewald
wrote:
> What's the problem with all of this? Code written for (1) is
> incompatible with code written for (2) which is incompatible with code
> written for (4). The asset managers listed on djangopackages use any
> of those thr
er where the
combined file is placed. You always use the same URL to refer to an
image. It's never ambiguous. BTW, method (4) has the same behavior as
Django's templates: {% extends %} and {% include %} are relative to
the root template folder, not the source file.
The only advantage of (2)
Hi Yuri,
On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
> wrote:
>> 2010/10/27 Mikhail Korobov :
>>> Why isn't it fine to have different URL rewriting schemes for
>>> diffe
2010/10/27 Mikhail Korobov :
> Why isn't it fine to have different URL rewriting schemes for
> different assets bundlers?
OK, sorry for not having explained it well. What I mean is this:
Imagine this code snippet in a reusable app's CSS file:
/* myapp/style.css */
div.icon {
background-image: u
Hi Mikhail,
On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov wrote:
> Hi Waldemar,
>
> Could you explain why is this should belong to django staticfiles app?
> This app has nothing to do with combining css files. It has one view
> (django.contrib.staticfiles.views.serve) in order to serve files i
On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald
wrote:
> OK, I just went through django-mediagenerator to check if there's
> anything else needed by staticfiles and I noticed that we need to have
> a standard for URLs in CSS files (e.g., url(image.png)).
>
> Sin
On Thu, Oct 21, 2010 at 10:48 PM, Luke Plant wrote:
> On Thu, 2010-10-21 at 20:25 +0200, Waldemar Kornewald wrote:
>
> To fully support one of the other assets managers you mention, we would
> need the admin and all contrib apps to get on board and use the template
> tags etc.
On Thu, Oct 21, 2010 at 11:43 PM, Jannis Leidel wrote:
>> Is staticfiles supposed to put "app/static/style.css" into
>> "/style.css" or "/app/style.css"? Currently it behaves
>> like the latter, but if it should behave like Django's templates we
>> need to fix the code.
>
> The latter is correct.
On Thu, Oct 21, 2010 at 10:04 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 1:25 PM, Waldemar Kornewald
> wrote:
>> My proposal would've been to not add staticfiles in the first place,
>> but it seems to be too late, now.
>
> If you think reverting the comm
On Thu, Oct 21, 2010 at 10:09 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 2:33 PM, Tobias McNulty
> wrote:
>> Ah, so realistically we should put all our media in 'static/', like
>> for templates, if we want to avoid conflicts with other apps. Would that be
>> worth mentioning as a co
stent. (2) is the
second best solution. It should be easy to adapt the code in
django-mediagenerator and make a little patch for staticfiles, so it
behaves like (4). What do you think?
In any case, staticfiles would need to rewrite URLs in its view, too.
Otherwise we can't provide a consiste
Hi Jakob,
On Thu, Oct 21, 2010 at 5:10 PM, Jacob Kaplan-Moss wrote:
> On Thu, Oct 21, 2010 at 3:50 AM, Waldemar Kornewald
> wrote:
>> With this reasoning we could as well add django-debug-toolbar, South,
>> django-registration and many other popular apps. What makes
>&g
On Thu, Oct 21, 2010 at 5:25 AM, Jannis Leidel wrote:
>> The core 'django.views.static.serve' and
>> 'django.core.context_processors.media' are deprecated in favor of the
>> staticfiles equivalents in contrib. Is the idea that the contrib app is a
>> stepping stone to providing core functionali
On Wed, Oct 20, 2010 at 10:13 PM, Jacob Kaplan-Moss wrote:
> On Wed, Oct 20, 2010 at 3:04 PM, Waldemar Kornewald
> wrote:
>> I wish that were the case. The staticfiles documentation says:
>>
>> """
>> Remember to run :djadmin:`collectstatic` whe
Hi Carl,
On Wed, Oct 20, 2010 at 10:53 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 20, 4:04 pm, Waldemar Kornewald wrote:
>> That's a funny combination of tools. :)
>> You don't really need django-staticfiles because in your case
>> django_compressor tak
Hi Carl,
On Wed, Oct 20, 2010 at 8:55 PM, Carl Meyer wrote:
> Hi Waldemar,
>
> On Oct 20, 1:40 pm, Waldemar Kornewald wrote:
> [snip]
>> However, what staticfiles does has almost nothing to do with "bigger
>> project" asset management. Just look at the
cts. So, why was this app added to Django? Most projects are
better off using a different solution, anyway.
BTW, I noticed a bug in the staticfiles view: It checks for "if
settings.DEBUG", but that should be "if not settings.DEBUG".
Also, staticfiles doesn't index "
en as a view factory. At least,
this is not much more magical than having non-obvious thread-safety
due to copy(). None of the solutions are perfect, but IMHO the thread-
safety advantages of the __new__ approach (i.e., internal state
created in __init__ is thread-safe) outweigh this minor detail bec
On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee
wrote:
> On Sun, Sep 26, 2010 at 1:24 AM, Waldemar Kornewald
> wrote:
>> On Sep 25, 4:21 pm, Russell Keith-Magee
>> wrote:
>>> My reason for wanting this is that I'm simply not an expert in any of
>>&
On Sep 25, 4:21 pm, Russell Keith-Magee
wrote:
> My reason for wanting this is that I'm simply not an expert in any of
> these backends. I know SQL quite well, but I haven't had occasion to
> try out other backends in depth. I can judge the technical merits of a
> patch based on what I know, but I
ify our
porting effort and allow us to reuse our existing unit tests and
project code.
Bye,
Waldemar Kornewald
--
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.
How often should I ping, so my patch won't be forgotten? :)
On Thu, Aug 19, 2010 at 9:38 AM, Jannis Leidel wrote:
> Am 19.08.2010 um 01:50 schrieb Waldemar Kornewald:
>
>> No comments means it's still not good enough and I'll never get it
>> into an acceptable
code. If someone uses a NoSQL backend
the new validation behavior would be enabled automatically.
Bye,
Waldemar Kornewald
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
--
You received this message because you
would be added (it's very easy to do,
anyway).
At some point we'll also need a solution for delegating the deletion
of related objects to the backend. This is needed at least for App
Engine, probably also for HBase, and maybe for some other DBs with
transaction support.
Bye,
Waldemar K
No comments means it's still not good enough and I'll never get it
into an acceptable shape? :)
Bye,
Waldemar
On Sun, Aug 15, 2010 at 7:13 PM, Waldemar Kornewald
wrote:
> On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald
> wrote:
>> On Thu, Jul 22, 2010 at 4:30 A
On Sat, Aug 14, 2010 at 1:45 PM, Waldemar Kornewald
wrote:
> On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee
> wrote:
>> I accept the need for this, but this seems like a bit of a wart. This
>> method wouldn't be required at all if the Form took a request
>> ar
#x27;otherapp.models.SomeModel.*': 'OtherBackend',
}
If you need more control you can use FILE_TRANSFER_BACKENDS which
works more like the routers API.
Bye,
Waldemar Kornewald
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonsp
uld be easy to add. The first two would ideally get an equivalent in
Django's ORM before they're implemented, but it should be possible to
provide separate functions for those features, too.
I'm just asking because I'm interested in hearing from other people
which problems we n
On Thu, Jul 22, 2010 at 4:30 AM, Russell Keith-Magee
wrote:
> On Sun, Jul 18, 2010 at 1:59 AM, Waldemar Kornewald
> wrote:
>> Hi Russell,
>> so, after our chat on IRC I've finally found the time to implement a
>> real proposal including unit tests. I've at
get_storage_backend() which returns
a storage backend for the given model/field combination. As a fallback
DEFAULT_STORAGE_BACKEND is used.
The API is also similar to DB routers. If any of those functions
returns None the next backend is tried (as defined in
settings.FILE_BACKENDS).
Please provide some fee
g to read through everything
> posted so far and try to post a summary and round-up to help us get
> refocused; gimme a few hours to pull that together and then let's try
> to reach towards a consensus.
Any results?
Bye,
Waldemar Kornewald
--
You received this message becau
Hi again,
so, does the proposal look fine for now, so I can actually make a
patch or can you already tell me now that there is a problem which
needs to be solved, first?
Bye,
Waldemar Kornewald
--
You received this message because you are subscribed to the Google Groups
"Django devel
On Thu, Jun 24, 2010 at 1:12 PM, Luke Plant wrote:
> On Thu, 2010-06-24 at 08:40 +0200, Waldemar Kornewald wrote:
>
>> The boolean is sufficient because those permission checks should be
>> done in the download view (or a router backend):
>>
>> if request.user.i
On Wed, Jun 23, 2010 at 11:06 PM, Robert Coup
wrote:
> On Thu, Jun 24, 2010 at 4:24 AM, Waldemar Kornewald
> wrote:
>> FileField gets a new method prepare_upload() which takes the following
>> arguments:
>> * request
>> * upload_url: the target URL of the upload vie
On Wed, Jun 23, 2010 at 2:58 AM, Russell Keith-Magee
wrote:
> On Wed, Jun 23, 2010 at 2:58 AM, Waldemar Kornewald
> wrote:
>> On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee
>> wrote:
>>> On Tue, Jun 22, 2010 at 2:55 PM, Waldemar Kornewald
>>> wrote:
On Tue, Jun 22, 2010 at 2:40 PM, Russell Keith-Magee
wrote:
> On Tue, Jun 22, 2010 at 2:55 PM, Waldemar Kornewald
> wrote:
> My initial impression of django-filetransfers is that you've
> constructed a lot of very complex infrastructure for what is
> ultimately a couple of
can become unresponsive.
Bye,
Waldemar Kornewald
--
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-devel
ng this (or a
similar) API in core, so there is a standard way to handle any kind of
upload/download solution? Or should the admin interface try to use
django-filetransfers if it's available (probably not; just thinking
aloud)?
Bye,
Waldemar Kornewald
--
You received this message because
ross nonrel
backends, so I think emulation is fine at least in this case.
> My goal for this week is going to be playing with cleaning up the
> abstractions in aggregates and F expressions (MongoDB has limited
> support for inplace updates, so this will be a useful test).
Cool. That&#
ange/extend it:
https://spreadsheets.google.com/ccc?key=0AnLqunL-SCJJdGhxSVZaQkNCcTlzM2d4OEc5dFRPUUE&hl=en
Bye,
Waldemar Kornewald
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-deve
:
* relatively easy for unit tests (new_instance())
* enforced thread-safety
* no special code in Django's URL routing
vs
* no-brainer for unit tests
* no enforced thread-safety (you can mistakenly create a global view instance)
* special code in Django's URL routing
Bye,
Waldemar K
On Thu, Jun 17, 2010 at 6:57 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 6:49 PM, Waldemar Kornewald
> wrote:
>> The one-instance approach is no more thread-safe than having a global
>> variable. In your example nothing bad will happen, but once we get to
>>
On Thu, Jun 17, 2010 at 6:08 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 2:08 PM, Waldemar Kornewald
> wrote:
>> On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki
>> wrote:
>>> Here's an example of a thread-safe view that works happily with just
a look at the Feed view in Django (or look at ModelAdmin from the
admin interface if you prefer):
http://docs.djangoproject.com/en/dev/ref/contrib/syndication/
You can customize the query that gets executed and you can customize
every single field that gets displayed in the feed. It's very
On Thu, Jun 17, 2010 at 1:42 PM, Patryk Zawadzki wrote:
> On Thu, Jun 17, 2010 at 1:20 PM, Waldemar Kornewald
> wrote:
>> Please take a deeper look at his code. He doesn't use __init__. He
>> uses __new__, so each request gets his own View instance.
>>
>&g
instance.
Instead of
aa = AwesomeAdd()
foo = aa(3, 5)
the __new__-based approach allows to do this:
foo = AwesomeAdd(3, 5)
IOW, the "constructor" directly returns an HttpResponse (foo) instead
of an AwesomeAdd instance.
Bye,
Waldemar Kornewald
--
You received this message because y
the current code would
unnecessarily instantiate the form two times if the form doesn't
validate.
Also, _load_config_values should guarantee that you don't pass
unsupported arguments. This should also work with inheritance.
Bye,
Waldemar Kornewald
--
You received this message because you
On Fri, Jun 11, 2010 at 5:25 PM, Russell Keith-Magee
wrote:
> On Thu, Jun 10, 2010 at 10:18 PM, Waldemar Kornewald
> wrote:
>> That's right. We believe that the long-term advantages of having a
>> common AutoField for everyone outweigh the short-term disadvantage of
&g
l, please
correct me if you meant something different.
So, the question (as far as I understand) is whether the code above is
actually used by so many developers that you could justify making
NoSQL support a second-class citizen.
Bye,
Waldemar Kornewald
--
You received this message because you a
On Thu, Jun 10, 2010 at 2:31 PM, Russell Keith-Magee
wrote:
> On Wed, Jun 9, 2010 at 4:25 AM, Waldemar Kornewald
> wrote:
>> By not supporting string-based primary keys the MongoDB and SimpleDB
>> communities will have to maintain their own version of all Django apps
>&g
On Tue, Jun 8, 2010 at 8:55 PM, Alex Gaynor wrote:
> On Tue, Jun 8, 2010 at 12:11 PM, Waldemar Kornewald
> wrote:
>> On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor wrote:
>>> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald
>>> wrote:
>>>> Why did y
On Tue, Jun 8, 2010 at 7:03 PM, Alex Gaynor wrote:
> On Tue, Jun 8, 2010 at 2:37 AM, Waldemar Kornewald
> wrote:
>> Why did you revert the AutoField patch? BTW, in the Django-nonrel
>> patch you'll find a few other changes which were related to AutoField:
>> For
t assigning a string to an
AutoField will fail, so we'll need to find a solution for that
(probably by fixing the unit tests).
Bye,
Waldemar Kornewald
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send emai
nstead:
(r'', 'views.DetailView', {'queryset': Thing.object.all()})
Bye,
Waldemar Kornewald
--
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...@googlegrou
On Jun 2, 11:31 pm, Luke Plant wrote:
> On Tuesday 01 June 2010 11:43:30 henning.schroe...@gmail.com wrote:
>
> > On May 30, 7:24 am, Waldemar Kornewald wrote:
> > > Maybe I missed something, but why don't you use __new__ instead
> > > of copying the instanc
Maybe I missed something, but why don't you use __new__ instead of
copying the instance?
Bye,
Waldemar
On May 29, 11:06 pm, Ben Firshman wrote:
> Luke, you're absolutely right that changing the definition of a view is a bad
> idea, it just seemed the best solution then.
>
> But don't worry, we'
ent Django-nonrel
feature set you could easily also support SimpleDB, CouchDB, Redis,
and other backends. I don't see any missing features that stand in the
way of achieving that goal. I hope our work can at least be used as a
starting point for the GSoC NoSQL project.
Bye,
Waldemar Kornewald
-
Hi Russell,
On May 18, 1:59 pm, Russell Keith-Magee
wrote:
> On Tue, May 18, 2010 at 5:08 PM, Alberto Paro wrote:
> > I'm developing a big application that does some complex mixing of database:
> > SQL and notSQL one.
> > I'm using the multidb to manage all the stuff in a django manner, using
>
On Thu, Apr 8, 2010 at 11:03 PM, flo...@gmail.com wrote:
> On Apr 8, 12:32 pm, Waldemar Kornewald wrote:
>
>> What I'm proposing is not a complete emulation of all features at all
>> cost, but simply an automation of the things that are possible and in
>> wide use o
e package that adds these
features. I'm just concerned that Alex' refactoring will make it more
difficult or even impossible to implement an emulation layer because
his goal is totally different.
Bye,
Waldemar Kornewald
--
You received this message because you are subscr
On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor wrote:
> On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald
> wrote:
>> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor wrote:
>>> No. I am vehemently opposed to attempting to extensively emulate the
>>> features of
rt doesn't really make sense
with Django. OTOH, if the goal is to make an abstraction around their
indexes they can all look very similar from the perspective of
Django's ORM (of course they have different "features" like sharding
or eventual consistency or being in-memory DBs o
able inheritance
>> unnecessarily in his code?
>>
>
> There's nothing about MTI that's inherently hard on a non-relational
> database, besides not being able to "select_related" the parent.
What if you filter on one field defined in the parent class and
anot
ld be very inefficient.
Denormalization is IMHO not the answer to this problem, either. Should
Django simply fail to execute such a query on those backends or should
the user make sure that he doesn't use multi-table inheritance
unnecessarily in his code?
Bye,
Waldemar Kornewald
--
You r
On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee
wrote:
> On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald
> wrote:
>> On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com wrote:
>>> I'm not really a developer on Django itself, but I am fairly
>>> int
onrel support.
We have people interested in adding MongoDB, CouchDB, and maybe
SimpleDB support. The current code should be abstract enough for
SimpleDB and probably also MongoDB (though, it would help to modify
AutoField to also support string values). Other DBs might need
additional changes,
es a special
property which is not part of the field values dictionary. In order to
emulate JOINs we must store the column names of the primary keys used
in the sql.Query instance.
So, do you think this is a good path to take?
Bye,
Waldemar Kornewald
--
http://twitter.com/wkornewald
http://bitbu
ctionality is mostly complete that other people offer help, mostly
> in the form of testing.
We are two developers who work closely together, but we don't feel
very comfortable hacking through the SQL layer without any help.
Bye,
Waldemar Kornewald
--
http://twitt
None/NULL. Do some DBs allow for a nullable pk or is the
query executed unnecessarily?
Bye,
Waldemar Kornewald
--
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...@googl
backend support into Django 1.3 (which is definitely
possible, so please don't vote -1 next time if this is your only
concern).
I understand if you're currently busy with finishing 1.2, but if
you're interested in helping when will you have time?
Bye,
Waldemar Kornewald
--
http
Hi Russell,
On Sat, Dec 5, 2009 at 2:58 PM, Russell Keith-Magee
wrote:
> On Sat, Dec 5, 2009 at 9:05 PM, Waldemar Kornewald
> wrote:
>> On Sat, Dec 5, 2009 at 12:10 PM, Russell Keith-Magee
>> wrote:
>>> The idea of using a function that returns a single string but d
those details.
They should only provide a high-level abstraction to the DB that is as
expressive and simple as possible. The details can be implemented via
add-ons, so everyone can map the DB abstraction to his real DB setup.
Bye,
Waldemar Kornewald
--
You received this message because you ar
ly have to define our own API in
the non-relational branch.
Bye,
Waldemar Kornewald
On Thu, Dec 3, 2009 at 5:10 PM, Russell Keith-Magee
wrote:
> Hi all,
>
> Alex Gaynor's GSoC project to add multiple database support to Django
> is on the final straight. The only piece of the puzzle
of Django.
Bye,
Waldemar Kornewald
--
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-developers+unsubscr...@g
me) once I have a chance to give the patch a
> final review.
Thanks a lot, Russell!
Andi, could you please add your App Engine email backend to our test project?
Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
pe you're much more likely to help. ;)
Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
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
Hi,
Russell and Alex, did you already look at QueryGlue? We really need to
discuss which branch the new query_class() should be in.
Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
On Mon, Oct 26, 2009 at 3:05 PM, Russell Keith-Magee
wrote:
>
> On Mon, Oct 26, 2009 at 8:46 PM, Waldemar Kornewald
> wrote:
>>
>> On Mon, Oct 26, 2009 at 1:12 PM, Russell Keith-Magee
>> wrote:
>>> To date, sql.Query is the right structure for all Django
. The point why we need QueryGlue is that the queries will
have to be manipulated and interpreted in order to emulate certain
features (e.g., joins) and its much easier to do this on the final
query tree than on its intermediate states.
Bye,
Waldemar Kornewald
--~--~-~--~~
e you should better reuse what we've
started and finish that together with us, so we all don't waste time
on refactoring everything twice?
Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
django mirror, so you at least get a consistent changeset history.
Bye,
Waldemar Kornewald
--
Bye,
Waldemar Kornewald
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
1 - 100 of 137 matches
Mail list logo
