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 w

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 Study.

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 li

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 ve

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 this

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 in

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. > > Regards,

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 t

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 django-developers+unsubscr...

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 DUTH

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 - https:/

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: > > https://www.googl

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&tbm=vid Best -- You received this message because yo

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 then

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 > ac

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

ges', 'django.contrib.staticfiles', 'mysqlApp' #this is app created ] DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'hospital', 'USER': 'root',

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 you

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 advanc

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 fr

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 https://docs.djangoproject.com/en/2.0/topics/db/queries/#spanning-multi-valued-relati

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') >>> Related.objects.filter(Q(main__field_two='2')|Q(main__field_one='1')

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') & Q(ent

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 the

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 wrote: > I have recently

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 to

Re: Django ORM query syntax enhancement

rderBy(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 S

Re: Django ORM query syntax enhancement

__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

Re: Django ORM query syntax enhancement

is 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 >> >> >&

Re: Django ORM query syntax enhancement

h 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 P

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=

Re: Django ORM query syntax enhancement

ing transforms is now possible since they are just > >>> >> >>>>>>>> Func > >>> >> >>>>>>>> expressions. > >>> >> >>>>>>>> Func(Func(Func('field_name'))) is no issue. > >>> >

Re: Django ORM query syntax enhancement

>> 3. Sounds like an OK idea, but I haven't looked into the >>> >> >>>>>>>> details >>> >> >>>>>>>> enough >>> >> >>>>>>>> to >>> >> >>>

Re: Django ORM query syntax enhancement

gt;>>>>>>> Cheers > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey > Zankevich > >> >>>>>>>> wrote: > >> >

Re: Django ORM query syntax enhancement

>>>> Cheers > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey > Zankevich > >> >>>>>>>> wrote: > >> >>>>>>&g

Re: Django ORM query syntax enhancement

gt; >> >>>>>>>> Part 1 above can be started now if you have the time or >> interest. >> >> >>>>>>>> We >> >> >>>>>>>> can >> >> >>>>>&

Re: Django ORM query syntax enhancement

; On Wednesday, 30 September 2015 04:49:54 UTC+10, Alexey > Zankevich > >> >>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>> Here is a list of issues to solve to support exp

Re: Django ORM query syntax enhancement

>>>>>>>> 1. Make Lookup.__init__ signature to support initialization with >> >>>>>>>>> F >> >>>>>>>>> objects >> >>>>>>>>> or string path (e.g. GreaterThan(F('user__id'), 10) or &

Re: Django ORM query syntax enhancement

shall support explicit lookups/transforms > >>>>>>>>> as > >>>>>>>>> argument as well - it's a kind of logical step, as without Q > >>>>>>>>> objects > >>>>>>>>> it will >

Re: Django ORM query syntax enhancement

;>>>>>> object >>>>>>>>> to Q object - filter will take already parsed lookup tree. >>>>>>>>> Example: >>>>>>>>> >>>>>>>>> Q(user__name__lower__unaccent__icontains='Bob&

Re: Django ORM query syntax enhancement

>> On Sunday, August 16, 2015 at 4:18:26 PM UTC+3, Alexey Zankevich >>> >>> >> wrote: >>> >>> >>> >>> >>> >>> Hi all, >>> >>> >>> >>> >>> >>> This topic is r

Re: Django ORM query syntax enhancement

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

Re: Django ORM query syntax enhancement

underscores. >>> >>> >>> There are lots of arguing related to it, anyway it has pros and >>> cons. >>> >>> >>> >>> >>> >>> Let's take a concrete example of querying a model: >>> >>>

Re: Django ORM query syntax enhancement

;>> >> >>> >>> >> >>> >>> Pros: >> >>> >>> >> >>> >>> 1. The syntax is easy to understand >> >>> >>> 2. Can be extended with custom transforms and lookups >> >>> >>> &g

Re: Django ORM query syntax enhancement

> >>> >>> >>> > >>> >>> >>> > GameSession.objects.filter(user_profile__last_login_date__gte=yesterday) > >>> >>> > >>> >>> Not easy to catch missing underscore between user and profile, is > it? > >>>

Re: Django ORM query syntax enhancement

gt;> >>> though, it's not easy to say whether it should be "user_profile" >>> >>> attribute or >>> >>> user.profile foreign key. >>> >>> >>> >>> 2. Query strings can't be reused, thus the approach

Re: Django ORM query syntax enhancement

> >>> We can't keep user__profile_login_date as a variable as in the first >> part >> >>> of the >> >>> expression we use a keyword argument, meanwhile in the second part - >> just >> >>> a >> >>> string. A

Re: Django ORM query syntax enhancement

gt;>> remembered or > >>> looked up in documentation. For example, "__gte" or "__lte" lookups > tend > >>> to be > >>> confused with "ge" and "le" due to similarity to methods "__ge__" and > >

Re: Django ORM query syntax enhancement

gt; >>> I was thinking a lot trying to solve those issues, keeping in mind Django >>> approaches. Finally I came up with solution to extend Q objects with dot >>> expression syntax: >>> >>> >>> GameSession.objecs.filter(Q.user.profile.last_

Re: Django ORM query syntax enhancement

gt; >>> GameSession.objecs.filter(Q.user.profile.last_login_date >= yesterday) >> >> Q is a factory instance for old-style Q objects. Accessing attribute by >> dot >> returns a child factory, calling factory will instantiate old-style Q >> object. >&

Re: Django ORM query syntax enhancement

gt; Q.user.profile > > > >>> Q(user__name='Bob') > > > It overrides operators, 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 > P

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

Re: Django ORM query syntax enhancement

gt; > I think it may look better with F objects, considering they are Field > >>> > references, and since the Lookups (Equal/GTE) parts accept F > >>> > expressions > >>> > anyway. I'm not too concerned about this particular detail though. > >>>

Re: Django ORM query syntax enhancement

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 we should > >>> > expand > >>> > the scope to include alternative filter syntax as a whole

Re: Django ORM query syntax enhancement

e right way 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 propo

Re: Django ORM query syntax enhancement

ter syntax as a whole > >>> > (expressions/callable 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 docume

Re: Django ORM query syntax enhancement

;).collate('fi') == 'Article1') >>> >>> > >>> >>> > Both of these approaches still suffer from "the string problem" >>> that >>> >>> > you're >>> >>> >

Re: Django ORM query syntax enhancement

meSession.objects.filter(Equal(Date(F.user.profile.last_login), >> >>> > datetime.now().date)) >> >>> > GameSession.objects.filter(E(F.user.profile.last_login).date() == >> >>> > datetime.now().date) >> >>> > >&g

Re: Django ORM query syntax enhancement

gt; > (expressions/callable 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 > >>>

Re: Django ORM query syntax enhancement

> > I think it may look better with F objects, considering they are >> Field >> >>> > references, and since the Lookups (Equal/GTE) parts accept F >> >>> > expressions >> >>> > anyway. I'm not too concerned about this particular d

Re: Django ORM query syntax enhancement

e 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 core &

Re: Django ORM query syntax enhancement

ed above. Then we can consider how all these > >>> > things > >>> > might work together, and clearly document why we've gone one way and > >>> > not > >>> > another. Obviously, alternatives can exist outside of core where the > &g

Re: Django ORM query syntax enhancement

5 23:18:26 UTC+10, Alexey Zankevich wrote: >>> >> >>> >> Hi all, >>> >> >>> >> This topic is related to the current ORM query syntax with >>> >> underscores. >>> >> There are lots of arguing related to it, a

Re: Django ORM query syntax enhancement

ally if we have fields with >> >> underscores. >> >> It's really easy to make a mistake by missing one: >> >> >> >> >>> >> >> >>> >> GameSession.objects.filter(user_profile__last_login_date__gte=yesterday) >> >

Re: Django ORM query syntax enhancement

>>> > >> >>> > GameSession.objects.filter(user__profile__last_login_date__gte=yesterday) \ > >> .order_by('user__profile__last_login_date') > >> > >> We can't keep user__profile_login_date as a variable as in the first > p

Re: Django ORM query syntax enhancement

a single argument only, very inconvenient >> when >> necessary to filter objects by range. >> >> I was thinking a lot trying to solve those issues, keeping in mind Django >> approaches. Finally I came up with solution to extend Q objects with dot >> expression

Re: Django ORM query syntax enhancement

t; Q > > > >>> Q.user.profile > > > >>> Q(user__name='Bob') > > > It overrides operators, so comparing factory with value returns a related Q > object: > > >>> Q.user.name == 'Bob' > > > Factory has several helper

Django ORM query syntax enhancement

27;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 string, which requred by order_by or select_related queryset methods: >>&

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

Hi Russ, Will get back with the benchmarks with performance benefits (if any). I do appreciate the complexity argument. We have been missing this API for a few years now, but been getting by ignoring the individual time stamp of the updates and being too lazy to follow up to see the feasibility.

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

I have long thought that bulk_save(objs) QuerySet method would be an useful addition to Django. The method would be defined as: Save the objects to the database using fastest available method. The objs can contain both objects that already exist in the database and thus nee

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 oppos

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 = 1,

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 a

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 querie

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 above > pseudo code would be

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

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 opposed do: My point is if this is acceptable then why have a .update() in ORM. I am sure by manually collating the updates in

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&utm_source=footer if you can provided evidence to back up your claim, I'll reverse my position on the n

#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. https://code.djangoproject

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 sense? This sounds pretty close > to > > your second soluti

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 compatibility to allow >> for two thing

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 users make a more > explicit choice wheth

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 NoS

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 message last year. I have t

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. It achieves this through roughly >> five layers that br

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. Currently, the best option is

Re: Django ORM support for NoSql databases

at'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 i don't really know if Django ORM is appropriate for NoSQL or not.

Re: Django ORM support for NoSql databases

ect. 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

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 ORM is entirely designed to translate between an object >

Re: Django ORM support for NoSql databases

Hello I think there is a difference between an ORM and an Document-Object Mapper as MongoEngine, I don't know if django ORM is designed to play a role adapted to a Document-Object Mapper, if not you can always use apps to that could be integrated to the django world and also a document m

Re: Django ORM support for NoSql databases

On Tue, Dec 17, 2013 at 4:50 PM, Chris Wilson wrote: > Hi all, > > > On Tue, 17 Dec 2013, Tom Evans wrote: > >> On Tue, Dec 17, 2013 at 3:35 PM, parisrocks >> wrote: >>> >>> Waiting for official Django ORM support for NoSql databases. >> >

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 reason NOT to relay emai

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 wrote: Waiting for official Django ORM support for NoSql databases. MongoDB (and the vast majority of NoSQL databases) are not relational databases, they are document oriented databases, they store

Re: Django ORM support for NoSql databases

oSQL 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 Django ORM support for NoSql databa

  1   2   >