Re: Potential bug with how Value works with Django ORM queries

Hi David, Thanks for response. I understand it now. I was assuming that Value auto typecasts to the field that we are querying. This makes sense. Thank you for taking time to respond. Cheers Nitin On Thursday, October 26, 2023 at 3:52:17 AM UTC-4 David Sanders wrote: > Hi Nitin, > > Not sure

Re: Potential bug with how Value works with Django ORM queries

Hi Nitin, Not sure what db you're using but will explain assuming PG. In this particular example, Django uses the `->` operator which requires that we compare jsonb types. The `__in=("Program1", "Program2")` is converted to jsonb via `DatabaseOperations.adapt_json_value()` where as `Value()`

Potential bug with how Value works with Django ORM queries

Hi I recently came across a very interesting scenario. I have a JSON Field which I want to query on. I was trying to do some performance optimizations and came across this If I query a non-JSON field like this: Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")]) and

Re: Standalon Django ORM

I think we already have this no? See https://docs.djangoproject.com/en/4.1/ref/databases/#s-third-party-notes for a list of 3rd party DB backends. On Tue, 13 Dec 2022 at 10:31, Vasanth Mohan wrote: > I second Jörg about better maintainability with tighter integrations. > > However, for the fun

Re: Standalon Django ORM

I second Jörg about better maintainability with tighter integrations. However, for the fun of stirring the pot, what's the opinion on letting Django define an API for the ORM and letting a library deal with the DB-specific implementation that generates the SQL for query? Django could have a

Re: Standalon Django ORM

I tend to believe the opposite is true. Django was/is a successor in its field, because it offers an "out-of-the-box" or "batteries included" experience. Subsequently parts were shaped as needed for that bigger picture, e.g. the ORM became what it is today. Does anyone still remember django

Standalon Django ORM

Hi, Given the small number of Django ORM maintainers, making the ORM standalone will, among other things, increase the adoption of Django and bring in new maintainers. An ORM inspired by Django ORM with over 3000+ stars: https://github.com/tortoise/tortoise-orm -- You received

Re: Django ORM query syntax enhancement

Hi Adam, I agree with some of your points. however djngo orm query syntax is the main pain point for anyone new to django orm. The reason those packages are not widely used is because most people dont know about them and not about this DEP. And most new users mainly end up learning built

Re: Django ORM query syntax enhancement

I would not be for merging anything into Django at this time. There are several libraries providing "enhanced" query syntax: django-orm-sugar, django-model-values, and django-natural-query. None of them seems to be particularly popular (<100 github stars, minimal PyPI downloads), an

Re: Django ORM query syntax enhancement

Hey all, can we have some consensus on this? Asif On Saturday, April 1, 2017 at 12:55:27 PM UTC+6 Alexey Zankevich wrote: > Hey all, > > Please check a draft DEP related to external query language support by > Django ORM https://github.com/django/deps/pull/40. > >

Re: Announcing CockroachDB support for Django ORM

This is the mailing list for the development of Django itself. Please use django-users for messages like this. On Monday, January 27, 2020 at 4:27:01 PM UTC-5, Charlotte Dillon wrote: > > https://pypi.org/project/django-cockroachdb/ > -- You received this message because you are subscribed to

Announcing CockroachDB support for Django ORM

https://pypi.org/project/django-cockroachdb/ -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: Django ORM Internals

Hello, I would suggest https://www.youtube.com/watch?v=bgV39DlmZ2U if you'd like to understand how the ORM is structured in layers. -- Aymeric. Le lun. 13 mai 2019 à 12:16, Adam Johnson a écrit : > Yes there isn't much documented on the ORM internals, but there are other > resources. The

Re: Django ORM Internals

Yes there isn't much documented on the ORM internals, but there are other resources. The DUTH videos are a great start and inspired me to get started contributing to Django. Specifically: - https://www.youtube.com/watch?v=CGF-0csOjPw - https://www.youtube.com/watch?v=-4jhPRfCRSM -

Re: Django ORM Internals

Great, thanks On Monday, May 13, 2019 at 1:17:08 PM UTC+4:30, J. Pic wrote: > > Hi Mahdi, > > I would suggest reading the code and test code in the tests/ directory for > the ORM. > > There might also be some videos from Django Under The Hood conferences, > found some here: > >

Re: Django ORM Internals

Hi Mahdi, I would suggest reading the code and test code in the tests/ directory for the ORM. There might also be some videos from Django Under The Hood conferences, found some here: https://www.google.com/search?q=Django+Under+The+Hood+orm=vid Best -- You received this message because you

Django ORM Internals

is a big package and contains lots of modules, I found it very difficult to understand the changes in the pull requests. Do you know any good resource about the internal structure of the django ORM? a blog post perhaps, anything to help me get started on the ORM internals. -- You received

Re: Django : Change Backend as mysql and create sample example using django ORM

com > *On Behalf Of *Raghavendrachari > k > *Sent:* 29 August 2018 09:42 > *To:* django-d...@googlegroups.com > *Subject:* Re: Django : Change Backend as mysql and create sample example > using django ORM > > > > Hi Sonali, > > Could you please paste the models.py

RE: Django : Change Backend as mysql and create sample example using django ORM

Of Raghavendrachari k Sent: 29 August 2018 09:42 To: django-developers@googlegroups.com Subject: Re: Django : Change Backend as mysql and create sample example using django ORM Hi Sonali, Could you please paste the models.py file ?? Might be there is some syntax error in the models you have created

Re: Django : Change Backend as mysql and create sample example using django ORM

Hi Sonali, Could you please paste the models.py file ?? Might be there is some syntax error in the models you have created. Regards, Raghav On Tue, Aug 28, 2018 at 9:41 PM parmeshwar deharkar < parmeshwardehar...@gmail.com> wrote: > hi sonali > you install sql libray in your project package

Re: Django : Change Backend as mysql and create sample example using django ORM

hi sonali you install sql libray in your project package then edit the setting.py file at django framework with database . I hope your problem will be solve... On Mon, Aug 27, 2018 at 4:54 PM Sonali Vighne wrote: > Hi, > I have tried a lot to change Django back-end as MySQL but not able to >

RE: Django : Change Backend as mysql and create sample example using django ORM

] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'hospital', 'USER': 'root', 'PASSWORD': '', 'HOST': 'localhost', 'PORT': '3306' } } From: django-developers@googlegroups.com On Behalf Of Raghavendrachari k Sent: 27 A

Re: Django : Change Backend as mysql and create sample example using django ORM

This list is dedicated to the discussion of developing Django itself, not answering usage questions. You might try the django-users group ( https://groups.google.com/forum/#!forum/django-users), or StackOverflow. On Monday, August 27, 2018 at 9:41:30 AM UTC-4, Raghavendrachari k wrote: > > if

Re: Django : Change Backend as mysql and create sample example using django ORM

if you explain briefly what is the issue you are facing , then we can can answer you ! Thanks Raghav On Mon, Aug 27, 2018 at 4:54 PM Sonali Vighne wrote: > Hi, > I have tried a lot to change Django back-end as MySQL but not able to > achieve this. > please help for the same. > > thanks in

Django : Change Backend as mysql and create sample example using django ORM

Hi, I have tried a lot to change Django back-end as MySQL but not able to achieve this. please help for the same. thanks in advance. :) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

Thank you all for the replies. @Josh Smeaton Essentially yes; specifically I was wondering whether I was failing to consider behaviour that couldn't be modeled via a Q object, since as you mention the current

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

These queries are actually not equivalent. Consider the following code: >>> r = Related.objects.create(field='related') >>> r.main_set.create(field_one='1', field_two='3') >>> r.main_set.create(field_one='2', field_two='4') >>>

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It sounds like you understand what the current behaviour is, and you think that it would be better modelled with Q objects, is that the case? I can see where you're coming from, as even the docs explain the difference loosely in terms of AND and OR. Q(entry__headline__contains='Lennon') &

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

On 03/30/2018 08:57 AM, Ryan Hiebert wrote: It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ It's also addressed in

Re: Django ORM Handling of Reverse Relationships and Multi-Value Relationships

It's a subtle difference between how a single filter works and two filters work together over to-many relationships. Here's a writeup that I found helpful: https://blog.ionelmc.ro/2014/05/10/django-sticky-queryset-filters/ On Thu, Mar 29, 2018 at 4:26 PM, Andrew Standley

Django ORM Handling of Reverse Relationships and Multi-Value Relationships

I have recently become acquainted with some ORM behaviour for reverse relationships that "makes no sense", and I'm hoping someone can explain the justification for the current behaviour. This specifically relates to `filter` behaviour referenced in 29271

Re: Django ORM query syntax enhancement

Hey all, Please check a draft DEP related to external query language support by Django ORM https://github.com/django/deps/pull/40. Regards, Alexey On Wednesday, March 22, 2017 at 10:07:51 AM UTC+3, Asif Saifuddin wrote: > > Hi Aric, > > I checked your package. it's nice

Re: Django ORM query syntax enhancement

y(FExpr(user__created), descending=True) > > In []: F.text.iexact('...') > Out[]: > > > > > On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich wrote: >> >> Hey all, >> >> Just want to announce recent changes in Django ORM Sugar library, w

Re: Django ORM query syntax enhancement

r(user__created)) In []: -F.user.created Out[]: OrderBy(FExpr(user__created), descending=True) In []: F.text.iexact('...') Out[]: On Thursday, October 6, 2016 at 10:04:56 AM UTC-7, Alexey Zankevich wrote: > > Hey all, > > Just want to announce recent changes in Django ORM Sugar librar

Re: Django ORM query syntax enhancement

>> >> I also like how lightweight the library is altogether. Well done! >> >> >> For those looking for a direct link, here you go: >> https://github.com/Nepherhotep/django-orm-sugar >> >> >> >> On Thursday, October 6, 2016 at 1:04:56 P

Re: Django ORM query syntax enhancement

re DRY. > > I also like how lightweight the library is altogether. Well done! > > > For those looking for a direct link, here you go: > https://github.com/Nepherhotep/django-orm-sugar > > > > On Thursday, October 6, 2016 at 1:04:56 PM UTC-4, Alexey Zankevich w

Re: Django ORM query syntax enhancement

+1 from me. I really like this approach to help making my queries more DRY. I also like how lightweight the library is altogether. Well done! For those looking for a direct link, here you go: https://github.com/Nepherhotep/django-orm-sugar On Thursday, October 6, 2016 at 1:04:56 PM UTC-4

Re: Django ORM query syntax enhancement

Hey all, Just want to announce recent changes in Django ORM Sugar library, which might be useful in future Django query syntax enhancement (if ever happens). 1. Now it supports indexes and slices: >>> Q.data.owner.other_pets[0].name='Fishy' Q(data__owner__other_pets__0__name='Fishy') &

Re: Django ORM query syntax enhancement

> > >> >>>>>>>>> 1. Make Lookup.__init__ signature to support initialization > with > >> >>>>>>>>> F > >> >>>>>>>>> objects > >> >>>>>>>>&

Re: Django ORM query syntax enhancement

t;>> 1. Make Lookup.__init__ signature to support initialization > with > >> >>>>>>>>> F > >> >>>>>>>>> objects > >> >>>>>>>>> or string path (e.g. GreaterThan(F('use

Re: Django ORM query syntax enhancement

rt >> 1. >> >> >>>>>>>> Part 1 >> >> >>>>>>>> may >> >> >>>>>>>> drive some of part 3. >> >> >>>>>>>> >> >> >>>>>>>> Cheers >>

Re: Django ORM query syntax enhancement

t; >> >>>>>>>>> F > >> >>>>>>>>> objects > >> >>>>>>>>> or string path (e.g. GreaterThan(F('user__id'), 10) or > >> >>>>>>>>&g

Re: Django ORM query syntax enhancement

>>>>>>>>> moving it >> >>>>>>>>> to a separate class method, e.g Lookup.build(lhs, rhs)), so I >> >>>>>>>>> assume >> >>>>>>>>> creating so-called util classes wh

Re: Django ORM query syntax enhancement

possible to perform complicated conditions (AND, OR, > NOT). > >>>>>>>>> In that case lookup/transform parsing should be moved from > >>>>>>>>> QuerySet > >>>>>>>>> object > >>>>>>>>>

Re: Django ORM query syntax enhancement

t__icontains='Bob') will internally >>>>>>>>> parse >>>>>>>>> it >>>>>>>>> and build next structure: >>>>>>>>> >>>>>>>>> Q(Icontains(Lower(Unaccent(F('user__name', 'Bob')

Re: Django ORM query syntax enhancement

t;>> >>> >>> >>> Let's take a concrete example of querying a model: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> &

Re: Django ORM query syntax enhancement

> >>> 1. Long strings is hard to read, especially if we have fields >> with >> >>> >>> underscores. >> >>> >>> It's really easy to make a mistake by missing one: >> >>> >>> >> >>>

Re: Django ORM query syntax enhancement

t;> >>> >>> Let's take a concrete example of querying a model: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> GameSession.objects.filter(user__profile__last_lo

Re: Django ORM query syntax enhancement

extended with custom transforms and lookups >> >>> >>> >> >>> >>> However, there are several cons: >> >>> >>> >> >>> >>> 1. Long strings is hard to read, especially if we have fields >> with >>

Re: Django ORM query syntax enhancement

gt; >>> >>> > >>> >>> Not easy to catch missing underscore between user and profile, is > it? > >>> >>> Even > >>> >>> though, it's not easy to say whether it should be "user_profile" > >>> >>> attribute or > >>> >>

Re: Django ORM query syntax enhancement

date: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) >>> >>> >>> \ >>> >>> .o

Re: Django ORM query syntax enhancement

the >> >>> expression we use a keyword argument, meanwhile in the second part - >> just >> >>> a >> >>> string. And thus we just have to type query path twice. >> >>> >> >>> 3. Lookup names not natural to Python language and require to be >> >>> rem

Re: Django ORM query syntax enhancement

t; >>> to be > >>> confused with "ge" and "le" due to similarity to methods "__ge__" and > >>> "__le__". > >>> > >>> 4. Lookup keywords limited to a single argument only, very > inconvenient > >>> wh

Re: Django ORM query syntax enhancement

e up with solution to extend Q objects with dot >>> expression syntax: >>> >>> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= >>> >>> yesterday) >>> >>> Q is a factory instance for old-style

Re: Django ORM query syntax enhancement

tance for old-style Q objects. Accessing attribute by >> dot >> returns a child factory, calling factory will instantiate old-style Q >> object. >> >> >>> Q >> >> >> >>> Q.user.profile >> >> >> >>> Q(

Re: Django ORM query syntax enhancement

rators, so comparing factory with value returns a related Q > object: > > >>> Q.user.name == 'Bob' > > > Factory has several helper functions for lookups which aren't related to > any > Python operators directly: > > >>> Q.user.name.icontains('Bob') > > > And helper to get query path as

Re: Django ORM query syntax enhancement

Hi Josh, As https://github.com/django/django/pull/5090 pull request merged into master, I wanted to extend django-orm-sugar library with some functionality, related to passing transforms or lookup objects. Currently it's not clear to me how lookups or transforms can be used in that way. I'm

Re: Django ORM query syntax enhancement

le transforms) as well as the dot field reference > >>> > notation you've proposed above. Then we can consider how all these > >>> > things > >>> > might work together, and clearly document why we've gone one way and > >>> > not &

Re: Django ORM query syntax enhancement

;> > might work together, and clearly document why we've gone one way and > >>> > not > >>> > another. Obviously, alternatives can exist outside of core where the > >>> > API is > >>> > available. > >>> > > >>> > I

Re: Django ORM query syntax enhancement

tside of core where the > >>> > API is > >>> > available. > >>> > > >>> > I'll be happy to work as the shepherd if needed. But I'd also like > some > >>> > input from Loic and Anssi especially, as well as others in the

Re: Django ORM query syntax enhancement

;> > > >>> > I'll be happy to work as the shepherd if needed. But I'd also like > some > >>> > input from Loic and Anssi especially, as well as others in the core > >>> > team > >>> > with some interest in the ORM. > >>

Re: Django ORM query syntax enhancement

ad. So I think your >>> >>> > idea >>> >>> > here could nicely coexist: >>> >>> > >>> >>> > GameSession.objects.filter(Equal(Date(Q.user.profile.last_login), >>> >>> > datetime.now().date)) >>> >>&g

Re: Django ORM query syntax enhancement

;> > references, and since the Lookups (Equal/GTE) parts accept F >> >>> > expressions >> >>> > anyway. I'm not too concerned about this particular detail though. >> >>> > >> >>> > A DEP is probably the right way to go here but I wonder if w

Re: Django ORM query syntax enhancement

vailable. > >>> > > >>> > I'll be happy to work as the shepherd if needed. But I'd also like > some > >>> > input from Loic and Anssi especially, as well as others in the core > >>> > team > >>> > with some interest in th

Re: Django ORM query syntax enhancement

ay to go here but I wonder if we should >> >>> > expand >> >>> > the scope to include alternative filter syntax as a whole >> >>> > (expressions/callable transforms) as well as the dot field reference >> >>> > notation you've proposed above. Then

Re: Django ORM query syntax enhancement

> >>> > > >>> > > >>> > On Sunday, 16 August 2015 23:18:26 UTC+10, Alexey Zankevich wrote: > >>> >> > >>> >> Hi all, > >>> >> > >>> >> This topic is related to the current ORM quer

Re: Django ORM query syntax enhancement

> >>> > > >>> > On Sunday, 16 August 2015 23:18:26 UTC+10, Alexey Zankevich wrote: > >>> >> > >>> >> Hi all, > >>> >> > >>> >> This topic is related to the current ORM query syntax

Re: Django ORM query syntax enhancement

; >>> >>> >> >>> >>> >> >>> GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) >>> >> >>> >> >>> >> Pros: >>> >> >>> >> 1. The syntax is easy to unde

Re: Django ORM query syntax enhancement

ot; >> attribute >> >> or >> >> user.profile foreign key. >> >> >> >> 2. Query strings can't be reused, thus the approach violates DRY >> >> principle. >> >> For example, we need to order results by last_login_da

Re: Django ORM query syntax enhancement

y path twice. > >> > >> 3. Lookup names not natural to Python language and require to be > >> remembered or > >> looked up in documentation. For example, "__gte" or "__lte" lookups > tend > >> to be > >> confused wi

Re: Django ORM query syntax enhancement

lly I came up with solution to extend Q objects with dot >> expression syntax: >> >> >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= yesterday) >> >> Q is a factory instance for old-style Q objects. Accessing attribute by >> dot >&g

Re: Django ORM query syntax enhancement

returns a related Q > object: > > >>> Q.user.name == 'Bob' > > > Factory has several helper functions for lookups which aren't related to > any > Python operators directly: > > >>> Q.user.name.icontains('Bob') > > > And helper to get query path as s

Django ORM query syntax enhancement

lookups which aren't related to any Python operators directly: >>> Q.user.name.icontains('Bob') And helper to get query path as string, which requred by order_by or select_related queryset methods: >>> Q.user.profile.last_login_date.get_path() 'user__profile__las

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

HI Anshuman, On Mon, Oct 20, 2014 at 2:03 PM, Anshuman Aggarwal < anshuman.aggar...@gmail.com> wrote: > Hi Russ, > Notwithstanding the performance, the current solution of doing 1000 > updates in a single transaction using ORM appears to be (in pseudocode > below): > > > > > > > as

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

Wouldn't a manual transaction (suitably rolled back after a bunch of changes) retain atomicity as well? The proposed solution using the UPDATE FROM from_list ... syntax and based on the postgres documentation link (below) does not seem to be any inferior to doing a single UPDATE XYZ SET A =

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

No, it doesn't. The atomicity semantics of update() are impossible to implement without it, this isn't the case for a multi-object UPDATE as far as I can tell. Alex On Sun, Oct 19, 2014 at 11:34 PM, Anshuman Aggarwal < anshuman.aggar...@gmail.com> wrote: > Thanks for the input Javier. Wouldn't

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

Thanks for the input Javier. Wouldn't a similar argument hold for: UPDATE books_book SET price = 10 where pk = 1, price = 25 where pk = 2 . Such a single SQL statement would also have similar benefits to having much less data to prepare, send and interpret vs having multiple update

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

On Mon, Oct 20, 2014 at 1:03 AM, Anshuman Aggarwal wrote: > The idea of having a .update() ORM construct is to be able to do this > without having to fall down to a manual transaction every time, otherwise > why have a DB level .update()...I am sure the performance of

Re: #23646 Enhancement: Updating multiple values in a single sql update using Django ORM

Hi Anshuman, As I mentioned when you raised this issue 2 days, ago: https://groups.google.com/d/msgid/django-developers/bac70fe2-3bbb-45c9-b805-5469e89f2754%40googlegroups.com?utm_medium=email_source=footer if you can provided evidence to back up your claim, I'll reverse my position on the need

#23646 Enhancement: Updating multiple values in a single sql update using Django ORM

Posting this Django Project ticket that I opened to track the enhancement request to update multiple rows with different values for the same field for a particular Django queryset in a single SQL query without having to write raw SQL. Please see the discussion there.

Re: Django ORM support for NoSql databases

On Thu, Dec 19, 2013 at 1:47 AM, Javier Guerra Giraldez wrote: > On Wed, Dec 18, 2013 at 12:18 PM, > wrote: > > > > Wouldn't an easy (i.e. straightforward) solution be to add an Django > "ODM" > > that mirrors the ORM wherever it makes

Re: Django ORM support for NoSql databases

On Thu, Dec 19, 2013 at 1:18 AM, wrote: > > > On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: >> >> >> My claim is that complete abstraction of the data store shouldn't be the >> goal. What we should be aiming for is sufficient API

Re: Django ORM support for NoSql databases

On Wed, Dec 18, 2013 at 12:18 PM, wrote: > > Wouldn't an easy (i.e. straightforward) solution be to add an Django "ODM" > that mirrors the ORM wherever it makes sense? This sounds pretty close to > your second solution, except choosing SQL vs NoSQL means

Re: Django ORM support for NoSql databases

On Tuesday, December 17, 2013 8:12:43 PM UTC-6, Russell Keith-Magee wrote: > > > My claim is that complete abstraction of the data store shouldn't be the > goal. What we should be aiming for is sufficient API compatibility to allow > for two things: > > * ModelForms wrapping a model from a

Re: Django ORM support for NoSql databases

On Wed, Dec 18, 2013 at 4:41 AM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 17 déc. 2013, at 20:38, Karen Tracey wrote: > > https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ > > > Interesting. Now I remember reading that

Re: Django ORM support for NoSql databases

On 17 déc. 2013, at 19:53, Javier Guerra Giraldez wrote: > On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin > wrote: >> Django’s ORM is entirely designed to translate between an object oriented >> API and SQL. That’s what its name says.

Re: Django ORM support for NoSql databases

On 17 déc. 2013, at 20:38, Karen Tracey wrote: > https://groups.google.com/d/msg/django-developers/0IuJssTt8tc/TxdXQ2D0thcJ Interesting. Now I remember reading that message last year. I have three reactions. First, Russell and I agree that the interest has faded.

Re: Django ORM support for NoSql databases

e, and a sql > submodule. There's very little SQL content in the base query module. That's > so that we can add a "noSQL" module at some later date. We've also been > aggressive about adding SQL-specific features (e.g., HAVING clauses, GROUP > BY clauses) to the ORM API. so, now

Re: Django ORM support for NoSql databases

So knowing what it takes to use the django ORM to work with a NoSQL DB, I hope I can provide some useful information. There are a few issues that we run into, so you can see that they are not fundamental problems. 1. Things you can do on a SQL system that you can't on NoSQL. - The big ones

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 2:05 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 17 déc. 2013, at 19:53, Javier Guerra Giraldez > wrote: > > > On Tue, Dec 17, 2013 at 12:16 PM, Aymeric Augustin > > wrote: > >> Django’s

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 4:50 PM, Chris Wilson <ch...@aptivate.org> wrote: > Hi all, > > > On Tue, 17 Dec 2013, Tom Evans wrote: > >> On Tue, Dec 17, 2013 at 3:35 PM, parisrocks >> <saravanan.sellathu...@gmail.com> wrote: >>> >>> Wa

Re: Django ORM support for NoSql databases

Hi Chris, On 17 déc. 2013, at 17:50, Chris Wilson wrote: > There is no particular reason NOT to do it, unless one wants Django's ORM > layer to remain fundamentally tied to SQL. I don’t understand your sentence. To me it’s as if you were saying “there is no particular

Re: Django ORM support for NoSql databases

Hi all, On Tue, 17 Dec 2013, Tom Evans wrote: On Tue, Dec 17, 2013 at 3:35 PM, parisrocks <saravanan.sellathu...@gmail.com> wrote: Waiting for official Django ORM support for NoSql databases. MongoDB (and the vast majority of NoSQL databases) are not relational databases, they are do

Re: Django ORM support for NoSql databases

goDB, there's a great community of NoSQL users waiting for an official > ORM support from Django like me. I would say Django with NoSQL ORM support > could actually make it more popular compared to its rivals Ruby on Rails or > even Java for that reason. > > Waiting for official Dj

Django ORM support for NoSql databases

Django with NoSQL ORM support could actually make it more popular compared to its rivals Ruby on Rails or even Java for that reason. Waiting for official Django ORM support for NoSql databases. Thanks -- You received this message because you are subscribed to the Google Groups "Django devel

Re: Django ORM enchantments

s probably too hard for me to implement in even near commit- > quality. > > These features would naturally make the ORM more powerful, but I see > some objections to these features: >  1. They will make the already complex ORM even more complex. This > will result in new bugs and it

Django ORM enchantments

naturally make the ORM more powerful, but I see some objections to these features: 1. They will make the already complex ORM even more complex. This will result in new bugs and it will be harder to add new features to the ORM. 2. Django ORM has the philosophy of "80/20". Meaning that the

Django ORM and multidimensional data

Hi all, Have django developers planned the integration of new model fields capable to store multidimensional data ? If it's not the case, how can I submit this implementation request ? By implementing this kind of basic types, I think it could be a way for the Django project to reach the

Re: Question for Django ORM developers

On Wed, Feb 24, 2010 at 7:57 AM, Russell Keith-Magee <freakboy3...@gmail.com > wrote: > On Wed, Feb 24, 2010 at 12:20 AM, P.R. <crico...@gmail.com> wrote: > > Hello, > > > > I have question about type of design patterns using in Django ORM. It > > is: Table

Re: Question for Django ORM developers

On Wed, Feb 24, 2010 at 12:20 AM, P.R. <crico...@gmail.com> wrote: > Hello, > > I have question about type of design patterns using in Django ORM. It > is: Table Data Gateway, Row Data Gateway, Active Record or Data > Mapper? .. Personally I think that it's mix of Row Da

  1   2   >