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
>> interested in non-relational databases, and some of the things being
>> said in this thread worry me a bit.
>
>
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
> interested in non-relational databases, and some of the things being
> said in this thread worry me a bit.
OK, if you read my mail literally I sound like "all" nonrel DBs are
Well, the simplest way is making DictionaryField more like CharField, except
that it's values will be stored in separate table. For example (application
name is "hardware", engine is sqlite3), if I define
*class HDD(models.Model):
form_factor = DictionaryField(max_length=10)
capacity = models.
2010/1/17 Mihail Lukin :
> Hi, Community
>
> Sometimes an application model include a lot of fields which are just
> dictionary values. Example:
>
> class HDD(models.Model):
> form_factor = models.ForeignKey(HDDFF)
> capacity = models.ForeignKey(HDDCap)
> interface = models.ForeignKey(HDDIntf)
>
Hi, Community
Sometimes an application model include a lot of fields which are just
dictionary values. Example:
class HDD(models.Model):
form_factor = models.ForeignKey(HDDFF)
capacity = models.ForeignKey(HDDCap)
interface = models.ForeignKey(HDDIntf)
...
and so on, where HDDFF, HDDCap and
I'm not really a developer on Django itself, but I am fairly
interested in non-relational databases, and some of the things being
said in this thread worry me a bit.
> 1. Nonrel DBs don't distinguish between INSERT and UPDATE
> On such DBs Model.save_base() shouldn't check if an entity already
> e
Russell Keith-Magee wrote:
That said - I really do want to see logging in Django's trunk. If we
can sort out the details in the background and get a good
implementation ready, it could easily be the first feature committed
for v1.3.
Agreed!
I like Vinay's suggestion for exactly the reason you
On Sat, Jan 16, 2010 at 6:26 AM, Russell Keith-Magee
wrote:
> Hi all,
>
> This is a quick call for comment on ticket #12624.
>
> This ticket proposes to make Django's test runner a class-based,
> rather than function based operation.
One thing:
http://docs.djangoproject.com/en/dev/releases/1.2/#
On Sat, Jan 16, 2010 at 8:26 AM, Russell Keith-Magee
wrote:
> Specifically, I want to make this change because I've had a couple of
> conversations in the recent past that have gone something like:
>
> Them: How do you make Django do X before/during/after a test run?
> Me: You write a custom tes
+1 for me, this will make my life a lot easier to implement a auto test
runner.
Is need to right up a proposal for change the code_change method a little,
but this is for another email.
Vitaly Babiy
On Sat, Jan 16, 2010 at 1:48 PM, Antoni Aloy wrote:
> +1 for me
>
> El 16/01/2010 15:26, "Russe
On Fri, Jan 15, 2010 at 3:55 AM, Russell Keith-Magee
wrote:
> And to be clear - a solid proposal isn't just "merge this branch". A
> patch/branch is one way to prove that you have thought about the
> problem in detail, but you also need to provide the discussion and
> description necessary to expl
+1 for me
El 16/01/2010 15:26, "Russell Keith-Magee"
escribió:
Hi all,
This is a quick call for comment on ticket #12624.
This ticket proposes to make Django's test runner a class-based,
rather than function based operation.
This makes it much easier to modify the individual parts of the
beha
Hi all,
This is a quick call for comment on ticket #12624.
This ticket proposes to make Django's test runner a class-based,
rather than function based operation.
This makes it much easier to modify the individual parts of the
behavior of the Django test runner. For example if you want to:
- no
On Sat, Jan 16, 2010 at 9:55 PM, Mat Clayton wrote:
> Thanks, I've looked over both sets of code, seem's fine to me. The only
> complex stuff is that Indexes can only be created on certain field types, so
> additional checks may need doing. Also different index types are available
> on different s
Thanks, I've looked over both sets of code, seem's fine to me. The only
complex stuff is that Indexes can only be created on certain field types, so
additional checks may need doing. Also different index types are available
on different storage engines, for MySQL. Would people want support for
sele
On Sat, Jan 16, 2010 at 8:56 PM, Mat Clayton wrote:
> Great, have to confess I don't know the ORM internals at all, so not sure
> how long this could take me, shall see what I can do. Also any indications
> of where/what to start looking for would be appreciated.
In the end, db_index_together wil
Great, have to confess I don't know the ORM internals at all, so not sure
how long this could take me, shall see what I can do. Also any indications
of where/what to start looking for would be appreciated.
'db_index_together' seems fair enough, will be trivial to change later
anyway.
With respect
On Sat, Jan 16, 2010 at 7:52 PM, Mat Clayton wrote:
> I know this isn't really related, but figure I would bring it up here. When
> working on optimizing our django app, it became very clear that one of the
> biggest issues as usual is Indexes, particularly multi column indexes, which
> at present
I know this isn't really related, but figure I would bring it up here. When
working on optimizing our django app, it became very clear that one of the
biggest issues as usual is Indexes, particularly multi column indexes, which
at present django doesnt appear to support.
I know ticket 373 http://c
19 matches
Mail list logo
