Hi Luke,
I have been thinking and researching a lot recently about SQLalchemy and
django integration.
Now SQLalchemy provides a devlarative orm extension too quite identical to
django orm[not same], django has also refactored a lot in db internals with
model meta refactore, expressions, new mi
On Wednesday, December 26, 2012 at 10:56 PM, Russell Keith-Magee wrote:
> That depends entirely on what you consider the goal of the ORM to be.
>
> You have assumed that the goal would be "allow an arbitrary query to run on
> any underlying data store, and run with equivalent efficiency". In t
On Thu, Dec 27, 2012 at 11:29 AM, Donald Stufft wrote:
> On Wednesday, December 26, 2012 at 10:00 PM, Russell Keith-Magee wrote:
>
> Why? Because we've gone to extraordinary lengths to make sure this sort of
> thing is at least theoretically possible.
>
> Although we use the term "ORM", and there'
On Wednesday, December 26, 2012 at 10:00 PM, Russell Keith-Magee wrote:
> Why? Because we've gone to extraordinary lengths to make sure this sort of
> thing is at least theoretically possible.
>
> Although we use the term "ORM", and there's currently only relational
> implementations of Django's
On Mon, Dec 24, 2012 at 7:10 AM, Donald Stufft wrote:
> On Sunday, December 23, 2012 at 4:08 PM, Florent Gallaire wrote:
>
> Django ORM should work for SQL and NoSQL DBMS.
> NoSQL integration in Django is a more interesting and needed subject,
> but who cares about that in the core team ?
>
> Why
On Sunday, December 23, 2012 at 4:08 PM, Florent Gallaire wrote:
> Django ORM should work for SQL and NoSQL DBMS.
> NoSQL integration in Django is a more interesting and needed subject,
> but who cares about that in the core team ?
>
>
Why should the Django Object Relational Mapper be modified
On 12/23/2012 10:08 PM, Florent Gallaire wrote:
SQLA is, as is its name indicates, a SQL ORM.
Django ORM should work for SQL and NoSQL DBMS.
Why? Because of name ?
NoSQL integration in Django is a more interesting and needed subject,
but who cares about that in the core team ?
There is no sing
SQLA is, as is its name indicates, a SQL ORM.
Django ORM should work for SQL and NoSQL DBMS.
NoSQL integration in Django is a more interesting and needed subject,
but who cares about that in the core team ?
-1
Cheers, Florent.
On Tue, Dec 4, 2012 at 4:19 AM, Ivan wrote:
> вторник, 4 декабря 201
вторник, 4 декабря 2012 г., 0:48:04 UTC+2 пользователь Ivan написал:
>
>
>1. Allows to use both, Django-ORM + SQLAlchemy. Single connection.
>SQLAlchemy's models are generated automatically form Django's models.
>https://github.com/Deepwalker/aldjemy
>
>
Sorry for bad link. This is th
Hi all,
I've viewed a few interesting solutions.
1. Allows to use both, Django-ORM + SQLAlchemy. Single connection.
SQLAlchemy's models are generated automatically form Django's models.
https://github.com/Deepwalker/aldjemy
2. Uses only Django's ORM, but allows to use 4 SQLBuilders
See also syntax evolution of peewee ORM, which initially was Django's
lightweight clone.
http://peewee.readthedocs.org/en/latest/peewee/upgrading.html#goals-for-the-new-api
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this disc
On Saturday, June 30, 2012 4:22:21 PM UTC+2, Luke Plant wrote:
>
>
> D) Write a patch to extend the ORM.
>
> D) This is basically too hard for most of us, including core developers.
> One reason is that the the code involved is not in the best shape. (More
> below. This might change if Anssi's
On Tuesday, July 3, 2012 7:59:26 AM UTC-5, Chris Wilson wrote:
>
> Hi Reinout,
>
> On Tue, 3 Jul 2012, Reinout van Rees wrote:
>
> > On 30-06-12 16:22, Luke Plant wrote:
> >> Also, in Django to date we've eschewed external dependencies. That has
> >> been partly due to the poor and confusing s
On Tuesday, July 3, 2012 9:42:28 AM UTC-4, Luke Granger-Brown wrote:
>
> In new versions of virtualenv the default has changed to
> --no-site-packages, at least on Linux. Is this not also the case for
> Windows?
>
> Luke
>
> Unfortunately, it is the same for windows. Every python project that
On Jul 3, 2012 1:59 PM, "Chris Wilson" wrote:
>
> Hi Reinout,
>
>
> On Tue, 3 Jul 2012, Reinout van Rees wrote:
>
>> On 30-06-12 16:22, Luke Plant wrote:
>>>
>>> Also, in Django to date we've eschewed external dependencies. That has
>>> been partly due to the poor and confusing state of Python pac
Hi Reinout,
On Tue, 3 Jul 2012, Reinout van Rees wrote:
On 30-06-12 16:22, Luke Plant wrote:
Also, in Django to date we've eschewed external dependencies. That has
been partly due to the poor and confusing state of Python packaging,
which is hopefully improving.
[snip]
Our current recommende
On 30-06-12 16:22, Luke Plant wrote:
Also, in Django to date we've eschewed external dependencies. That has
been partly due to the poor and confusing state of Python packaging,
which is hopefully improving.
[snip]
Our current recommended installation method is via pip [2], and we would
be doing
On Jul 2, 5:57 am, Anssi Kääriäinen wrote:
> In step 1 Django constantly keeps the correct join information and
> filtering conditions available. These are ready to be converted into
> SQL on the spot. In addition, some information is kept available, but
> it isn't processed yet. For example: se
On Jul 1, 12:53 pm, Andrew Godwin wrote:
>
> Ah, interesting. Alembic doesn't appear to support fully mutating SQLite
> databases, which is the really gnarly part of the South code I'd love to
> outsource. Looks like there's still plenty of work to be done no matter
> what happens.
While I'm qu
On 1 heinä, 00:11, Luke Plant wrote:
> On 30/06/12 20:23, Anssi Kääriäinen wrote:
>
> > TL;DR ;) But I intend to do so shortly.
>
> > For now I have to comment on the "clear up sql/query.py" part. I am
> > doubtful if moving to SQLAlchemy will solve the sql/query.py and sql/
> > compiler.py comple
Ehhm,
version numbers aren't decimal numers. 2.0 doesn't have to wait for 1.9.
Maybe even drop python 2 for django 2.0?
Harro
On Saturday, 30 June 2012 21:25:07 UTC+2, Jacob Kaplan-Moss wrote:
>
> Wow. There's really a lot to think about here, and I'm only just
> starting. Thanks for putting t
> I am pretty sure SQLAlchemy-Migrate has fallen out of favor. You should
> check Alembic, http://alembic.readthedocs.org/en/latest/.
Ah, interesting. Alembic doesn't appear to support fully mutating SQLite
databases, which is the really gnarly part of the South code I'd love to
outsource. Looks
On Sunday, July 1, 2012 6:11:34 AM UTC-5, Andrew Godwin wrote:
>
> Nice to see this after you mentioned it a couple of weeks ago, Luke! I'm
> very slightly in favour of the whole idea, but I'm skeptical about the
> amount of work this will require in the DB backend, and what that means
> for the
On 30/06/12 15:22, Luke Plant wrote:
> Hi all,
>
> A good while back I put forward the idea of using SQLAlchemy Core in
> Django [1]. Having had more experience working with SQLAlchemy, I'm
> putting that idea forward as a formal proposal, as I mentioned in a more
> recent thread here.
>
> Apolog
+1: I have my fair share of Django/SQLAlchemy frankensteins. It kind of
works, but the resulting creature is ugly.
I've used Flask for some projects and I'm really impressed by the power of
SQLAlchemy.
--
You received this message because you are subscribed to the Google Groups
"Django develo
On 30/06/12 20:23, Anssi Kääriäinen wrote:
> TL;DR ;) But I intend to do so shortly.
>
> For now I have to comment on the "clear up sql/query.py" part. I am
> doubtful if moving to SQLAlchemy will solve the sql/query.py and sql/
> compiler.py complexities.
>
> I have little knowledge of SQLAlche
On 30/06/12 20:25, Jacob Kaplan-Moss wrote:
> Before we do get too deep into this, however, I want to talk about
> this "Django 2.0" thing:
>
> Clearly there will be something called "Django 2.0" at some point --
> after 1.9, if we get there, comes 2.0. However, I think it would be a
> mistake to
On 30 kesä, 22:25, Jacob Kaplan-Moss wrote:
> Before we do get too deep into this, however, I want to talk about
> this "Django 2.0" thing:
>
> Clearly there will be something called "Django 2.0" at some point --
> after 1.9, if we get there, comes 2.0. However, I think it would be a
> mistake to
Wow. There's really a lot to think about here, and I'm only just
starting. Thanks for putting this together, Luke: I know it's been
something that's been discussed a ton, but until now nobody's really
done the due diligence to figure out exactly what the process and
ramifications would be.
Before
On 30 kesä, 17:22, Luke Plant wrote:
> Hi all,
>
> A good while back I put forward the idea of using SQLAlchemy Core in
> Django [1]. Having had more experience working with SQLAlchemy, I'm
> putting that idea forward as a formal proposal, as I mentioned in a more
> recent thread here.
>
> Apologi
30 matches
Mail list logo
