Hi Waldemar, Alex,
why you didn't do different threads for the different issues? :\
Regarding getting .filter() to work, I suggest we will use explicit
and implicit indexes, something like this:
class User(models.Model):
username = models.CharField(max_length=200, db_index=True) #
db_index=True should add the third line implicitly
email = models.CharField(max_length=200) # db_index=True can help,
but we have to go explicit here.
email = models.CharField(max_length=200, unique=True,
db_index='lowercase') # further ideas on lowercase support
#username_index = models.Index(['username'], 'pk') # line 3
email_index = models.Index(['email'], 'pk',
filter={'email':'lowercase'}) # line 4
...
And user will write:
users = User.objects.filter(email_index__startswith='me@')
Or:
class UsernameIndex(models.Index):
model = User
keys = ['category', 'email']
values = ['id']
def clean_email(value):
return value.lower()
and the user writing:
users = UsernameIndex.objects.filter(email__startswith='me@', category='staff')
But I don't think it has related to GSoC at all.
And this can be made outside of Django.
The same for Counters:
class User(models.Model):
username = models.CharField(max_length=200, db_index=True)
email = models.CharField(max_length=200)
category = models.CharField(max_length=20, choices=(('S', 'Staff'),
('U', 'User'))
counter = aggregates.Counter('category') # count number of users by category
I think, we should go with a separate Django proposal(s), don't put
that on Alex's shoulders.
What Alex will need to provide, is a way to assign a hook for
.filter() from QuerySet, which probably should be put into some kind
of NosqlManager (which will replace Manager at User.objects).
On Thu, Apr 8, 2010 at 8:08 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>> On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald <wkornew...@gmail.com>
>> wrote:
>>> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor <alex.gay...@gmail.com> wrote:
>>>> No. I am vehemently opposed to attempting to extensively emulate the
>>>> features of a relational database in a non-relational one. People
>>>> talk about the "object relational" impedance mismatch, much less the
>>>> "object-relational non-relational" one. I have no interest in
>>>> attempting to support any attempts at emulating features that just
>>>> don't exist on the databases they're being emulated on.
>>>
>>> This decision has to be based on the actual needs of NoSQL developers.
>>> Did you actually work on non-trivial projects that needed
>>> denormalization and in-memory JOINs and manually maintained counters?
>>> I'm not making this up. The "dumb" key-value store API is not enough.
>>> People are manually writing lots of code for features that could be
>>> handled by an SQL emulation layer. Do we agree until here?
>>>
>>
>> No, we don't. People are desiging there data in ways that fit their
>> datastore. If all people did was implement a relational model in
>> userland code on top of non-relational databases then they'd really be
>> missing the point.
>
> Then you're calling everyone a fool. :) What do you call a CouchDB or
> Cassandra index mapping usernames to user pks? Its purpose it exactly
> to do something that relational DBs provides out-of-the-box. You can't
> deny that people do in fact manually maintain such indexes.
>
> So, you're suggestion to write code like this:
>
> # ----------
> class User(models.Model):
> username = models.CharField(max_length=200)
> email = models.CharField(max_length=200)
> ...
>
> class UsernameUser(models.Model):
> username = models.CharField(primary_key=True, max_length=200)
> user_id = models.IntegerField()
>
> class EmailUser(models.Model):
> email = models.CharField(primary_key=True, max_length=200)
> user_id = models.IntegerField()
>
> def add_user(username, email):
> user = User.objects.create(username=username, email=email)
> UsernameUser.objects.create(username=username, user_id=user.id)
> EmailUser.objects.create(email=email, user_id=user.id)
> return user
>
> def get_user_by_username(username):
> id = UsernameUser.objects.get(username=username).user_id
> return User.objects.get(id=id)
>
> def get_user_by_email(email):
> id = EmailUser.objects.get(email=email).user_id
> return User.objects.get(id=id)
>
> get_user_by_username('marcus')
> get_user_by_email('mar...@marcus.com')
> # ----------
>
> What I'm proposing allows you to just write this:
>
> # ----------
> class User(models.Model):
> username = models.CharField(max_length=200)
> email = models.CharField(max_length=200)
> ...
>
> User.objects.get(username='marcus')
> User.objects.get(email='mar...@marcus.com')
> # ----------
>
> Are you seriously saying that people should use the first version of
> the code when they work with a simplistic NoSQL DB (note, it's how
> they work today with those DBs)?
>
>>> * Django apps written for NoSQL will be portable across all NoSQL DBs
>>> without any code changes and in the worst case require only minor
>>> changes to switch to SQL
>>> * the resulting code is shorter and easier to understand than with a
>>> separate API which would only add another layer of indirection you'd
>>> have to think about *every* (!) single time you work with models (and
>>> if you have to think about this while writing model code you end up
>>> with potentially a lot more bugs, as is actually the case in practice)
>>> * developers won't have to use and learn a different models API (you'd
>>> only need to learn an API for specifying "optimization" rules, but the
>>> models would still be the same)
>>>
>>
>> Uhh, the whole point of htis is that there is only a single API.
>
> And what you're suggesting is an API whose semantics are different on
> every single backend? How is that better? The indexing API would at
> least look and behave the same on all backends, so it's a "learn once
> and use anywhere" experience.
>
>>> What if you filter on one field defined in the parent class and
>>> another field defined on the child class? Emulating this query would
>>> be either very inefficient and (for large datasets) possibly return no
>>> results, at all, or require denormalization which I'd find funny in
>>> the case of MTI because it brings us back to single-table inheritance,
>>> but it might be the only solution that works efficiently on all NoSQL
>>> DBs.
>>>
>>
>> Filters on base fields can be implemented fairly easily on databases
>> with IN queries. Otherwise I suppose it raises an exception.
>
> How would that be implemented with an IN filter (you have two
> different tables)? What would the (pseudo-)code look like?
>
> 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...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
