Just out of interest,
This SQL-API sounds remarkably similar to ROE in smalltalk. Did you guys
get any inspiration from this particular project ?
regards,
Huy
A few months past, Ian Bicking (of SQLObject fame) presented an idea for
a SQL-API which would overlap significantly with SQLAlchemy.
Michael Bayer wrote:
lets collaborate, but lets come up with some semblance of a real spec
first. this before cracking open SQLAlchemy which in any case would
only be one particular implementation of many possible ones, and
shouldnt have to change its filestructure and release schedule around
I just discovered that the approach I had planned for my __init__-constructor
does not work. When SA calls the __init__ method of my class, it does not pass
any parameters and the attributes defined for this class/object do not exist
yet.
Is there a way to access attributes in the __init__ -me
dan -
no need to get defensive, the list has had enough flame wars for one
day.
this session context stuff is so not a big deal. we can go around
and around, its not going to go anywhere until you answer me this
question:
we agree, that there should be some way to turn on this feature
Michael Bayer wrote:
On May 2, 2006, at 10:13 PM, Daniel Miller wrote:
If you're interested, I have lot's of comments like this on various
parts of the SQLAlchemy API.
im sure you do, but one thorny issue of SA is that it supports multiple
programming styles, particularly in 0.2, where y
Clark C. Evans wrote:
[cut short - sorry]
How does this impact SQLAlchemy? Well, frankly, it need not if you so
choose. However, I think it would be a huge boon to SQLAlchemy if you
all wanted to play along. Assuming that the project was bootstrapped
from some of your existing modules:
-
Hi Clark,
Let me start by saying that I appreciate your efforts to bring the
conversation back to things that can be done together. You started off
with the suggestion of building up a new SQL-API, and then migrated
toward using the SQLAlchemy code as a starting point.
I see where Jonathan is co
lets collaborate, but lets come up with some semblance of a real spec
first. this before cracking open SQLAlchemy which in any case would
only be one particular implementation of many possible ones, and
shouldnt have to change its filestructure and release schedule around
just to meet a p
This one time, at band camp, Michael Bayer wrote:
> result = usermapper.select_by(address='[EMAIL PROTECTED]').order_by
>(addresstable.c.address)[4:15]
>
>will add "LIMIT 4 OFFSET 15 ORDER BY addresses.address" to the
>generated query before executing.
I'm not intimately familiar with LIM
This one time, at band camp, Michael Bayer wrote:
>sorry, wasnt being accurate. yeah, it does that. too much coffee
>today.
Or not enough. :-)
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done qui
sorry, wasnt being accurate. yeah, it does that. too much coffee
today.
On May 10, 2006, at 8:33 PM, Jamie Wilkinson wrote:
This one time, at band camp, Michael Bayer wrote:
result = usermapper.select_by(address='[EMAIL PROTECTED]').order_by
(addresstable.c.address)[4:15]
will add
Uncle! Uncle!
I think this conversation has come to a close. The SQLAPI project
is based on the premise that a layer between DB-API and a full ORM would
be useful; and more specifically, that this separate layer should be a
distinct project with its own trunk and release schedule.
I've had a t
On 5/10/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
On Wed, May 10, 2006 at 04:00:01PM -0600, Jonathan Ellis wrote:| There are any number of projects that can provide warm fuzzy learning| experiences, but given limited funds, it only makes sense to give| priority to ones that will benefit other P
As theres a lot of clamor for this lately, FYI to those looking for a
more flexible "select_by". the SelectResults extension can give you
a lot of what youre looking for.
from sqlalchemy.ext.selectresults import SelectResultsExt
addressmapper = mapper(Address, addresstable)
On Wed, May 10, 2006 at 04:00:01PM -0600, Jonathan Ellis wrote:
| There are any number of projects that can provide warm fuzzy learning
| experiences, but given limited funds, it only makes sense to give
| priority to ones that will benefit other Python developers as well.
You dramatically unders
On 5/10/06, Clark C. Evans <[EMAIL PROTECTED]> wrote:
On Wed, May 10, 2006 at 12:35:04PM -0600, Jonathan Ellis wrote:| "Hey guys, you have a working codebase that does everything we need, but| some of us have a severe case of NIH and would rather you spend a huge
| amount of effort conforming to ou
On Wed, May 10, 2006 at 05:45:11PM -0400, Michael Bayer wrote:
| no, thats not good enough, the mechanism by which SQLAlchemy
| generates the SQL can also be totally separated from the constructs.
| the constructs dont know anything about their own compilation. you
| might talk about one or
On May 10, 2006, at 4:18 PM, Clark C. Evans wrote:
| This is complicated by the fact that SQLAlchemy's SQL construction
| facilities are highly tuned at this point and have a lot of subtle
| features that are not only difficult to implement, but are also very
| critical, for reasons that may no
On May 10, 2006, at 2:17 PM, Ian Bicking wrote:
But I'm also concerned that it requires the structures contain a
lot more functionality, because they have to be able to portably
express fairly high-level ideas. Off the top of my head, the
difference between a database that uses sequences an
On Wed, May 10, 2006 at 01:41:23PM -0700, Ed Suominen wrote:
| So why is it unrealistic to imagine that these lower-level capabilities
| of SQLAlchemy, which are already in place, working, and wonderfully
| documented, could be adopted as the universal solution you're looking
| for? If there's some
> - defining an exception hierarchy corresponding with the
>SQL-92 and SQL-99 specifications.
Unless I misunderstand it, I don't see a great value in this one.
There's already an exception hierarchy which is defined by DBAPI2,
and is (kind of) supported by implementations. The support in SQ
On 5/10/06, Ed Suominen <[EMAIL PROTECTED]> wrote:
Ian, you might be interested to know that I only use the lower-levelselect, update, etc. capabilities of SQLAlchemy and have no currentplans to use the mappers. I have a lot of SQL experience and justhaven't found that higher level of abstraction u
Ian, you might be interested to know that I only use the lower-level
select, update, etc. capabilities of SQLAlchemy and have no current
plans to use the mappers. I have a lot of SQL experience and just
haven't found that higher level of abstraction useful in my
applications. However, I do find SQL
Ed Suominen wrote:
The question I would ask is this: What does SQLAlchemy lack that is
sought in this proposed SQL-API, and how much demand is there for that
functionality?
It's not what SQLAlchemy lacks, it's what it has. It's too much all at
once. It's scope does not fit what I want, and I
On Wed, May 10, 2006 at 01:01:51PM -0400, Michael Bayer wrote:
| Im not really sure what "duplicating effort" you have made, perhaps
| you could show me some examplesi havent heard anything about the
| current userbase having to "duplicate" parts of SA at all
I'm not a current user of SA,
On Wed, May 10, 2006 at 01:02:36PM -0700, Ed Suominen wrote:
| The question I would ask is this: What does SQLAlchemy lack that is
| sought in this proposed SQL-API, and how much demand is there for that
| functionality?
I, unfortunately, confounded two issues here. One of them is the
concrete wo
On Wed, May 10, 2006 at 12:35:04PM -0600, Jonathan Ellis wrote:
| "Hey guys, you have a working codebase that does everything we need, but
| some of us have a severe case of NIH and would rather you spend a huge
| amount of effort conforming to our (vapor) api rather than build on yours."
Ok. Can
Jonathan Ellis wrote:
> "Hey guys, you have a working codebase that does everything we need,
> but some of us have a severe case of NIH and would rather you spend
> a huge amount of effort conforming to our (vapor) api rather than
> build on yours."
>
> Honestly that is how SQL-API comes across
"Hey guys, you have a working codebase that does everything we need, but some of us have a severe case of NIH and would rather you spend a huge amount of effort conforming to our (vapor) api rather than build on yours."
Honestly that is how SQL-API comes across to me.
Michael Bayer wrote:
On May 10, 2006, at 1:32 PM, Ian Bicking wrote:
I've actually been wondering if a further division would be better.
Instead of defining objects with particular functionality, focus on
simpler protocols (aka magic methods), separately providing
implementations of that.
On May 10, 2006, at 1:32 PM, Ian Bicking wrote:
I've actually been wondering if a further division would be better.
Instead of defining objects with particular functionality, focus on
simpler protocols (aka magic methods), separately providing
implementations of that. The model that SQLAl
Michael Bayer wrote:
But if the PEP-making process is interested in what SQLAlchemy does and
how it does it, then show me what list to sign up on; while I have a
lot of trouble following the typical "PEP-oriented" discussion, I can
certainly offer my thoughts.
Probably the most appropriate
Clark C. Evans wrote:
A few months past, Ian Bicking (of SQLObject fame) presented an idea for
a SQL-API which would overlap significantly with SQLAlchemy. The goal is
to represent SQL as Python objects and provide other helpful features
(such as information schema introspection) which are not pa
On May 10, 2006, at 1:01 PM, Michael Bayer wrote:
its main goal is to provide Python with a very powerful, stable and
useable "results-based" SQL toolset, giving it a great advantage
over other development platforms that threaten its relevance.
clarification: giving *Python* an advantage
Hi Clark -
Im not really sure what "duplicating effort" you have made, perhaps
you could show me some examplesi havent heard anything about the
current userbase having to "duplicate" parts of SA at all; just
people building new things on top of it (like ActiveMapper, SQLSoup
and Pocoo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10 May 2006, at 5:56 PM, Jonathan Ellis wrote:
On 5/10/06, alanp <[EMAIL PROTECTED]> wrote:
The problem is that the commit in the parent process fails with a
psycopg error (ProgrammingError: "SET TRANSACTION ISOLATION LEVEL...")
when trying to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm clearly being an idiot but can't figure out how/where. I've had a
look through parts of the SA code but aren't getting any closer to
finding what is causing my problem.
The synopsis of the problem:
engine = ProxyEngine()
jobs = Tabl
Hi,
Does anyone try to use SA with mx.ODBC? I made some attempts but I
failed and I don't know if I'm doing something wrong or it just doesn't
work together?
I copy-pasted databases/sqlite to use mx.ODBC.Windows module and cut
almost everything to check if at least the connection works. I fail
38 matches
Mail list logo
