I agree with Babatunde. I think it would be too much of a barrier to entry and tries to solve some of the problems that the ORM/SQL in general solve or are intended to solve (generalizability). I'd personally rather enhance the ORM where necessary, or suggest that if you plan on switching between databases in an application with raw sql, you consider some method for setting a flag that indicates which version of raw sql to send. But maybe I'm underestimating the need for this sort of feature. -Nick
On Sat, Oct 6, 2012 at 9:59 AM, Babatunde Akinyanmi <tundeba...@gmail.com>wrote: > IMO, 'fake sql' would be another layer of abstraction *like the the > ORM* over different databases that don't work the same way. The result > would be the same. Since the ORM works fine, the ORM could be improved > to cater for some of these more complex cases. It leaves using django > a matter of learning python and not python and another sql language. > My 50 kobo > > On 10/6/12, Yugal Jindle <yugalm...@gmail.com> wrote: > > *Note :* > > > > - I know we have `Django ORM` already that keeps things database > > independent and converts to the database specific `SQL` queries. > > - Once things starts getting complicated it is preferred to write `raw > > SQL` queries for better efficiency. > > - When you write `raw sql` queries your code gets trapped with the > > database you are using. > > - I also understand its important to use the full power of your database > > that can-not be achieved with the `django orm` alone. > > > > *My Question :* > > > > - Until I use any database specific feature, why should one be trapped > > with the database. > > - For instance : > > > > We have a query with multiple joins and we decided to write a raw sql > >> query. Now, that makes my website `postgres` specific. Even when I > >> have not used any postgres specific feature. > > > > > > I feel there should be some `fake sql` language which can translate to > any > > database's sql query. Even Django's ORM can be built over it. So, that if > > you go out of ORM but not database specific - you can still remain > database > > > > independent. > > > > I asked the same question to `Jacob Kaplan Moss` (In person) : > > > > - He advised me to stay with the database that I like and endure its > whole > > > > power, to which I agree. But my point was not that we should be `database > > independent`. > > - My point is we should be database independent until we use a database > > specific feature. > > > > * > > * > > *Please explain, why should be there a `fake sql` layer over the actual > sql > > > > ?* > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/django-users/-/cQW4Vpc9ueYJ. > > To post to this group, send email to django-users@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/django-users?hl=en. > > > > > > -- > Sent from my mobile device > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
