On 7/28/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
> those are fine with me. if someone could add a ticket and/or
> implement that would be helpful.
http://www.sqlalchemy.org/trac/ticket/696
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
You re
those are fine with me. if someone could add a ticket and/or
implement that would be helpful.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@goog
On Friday 27 July 2007 23:18:17 Paul Johnston wrote:
>
> It's been great to see the recent discussions on this. An area I've
> been meaning to do some more work on for a while. I've noticed
> there are two main schools of thought on this issue:
>
> 1) Some people want the database layout to be com
For me, starting off with SQLAlchemy, "metadata" immediately made
sense, because I'd heard and used the term before in the context of
databases. After using SQLAlchemy for a while it seems like metadata
is pretty well true to it's name. The word "catalog", on the other
hand, means nothing to me in
[EMAIL PROTECTED] wrote:
>
>> > [...]
>> > so waht you want is this:
>> >
>> > mapper(X, table, properties={
>> > 'x':table.c.x,
>> >'y':table.c.y
>> > }, explicit_columns=True)
>> >
>> >
>> > which means, set up x and y, but dont go setting up everything
>> > else inside of table.c (i.e.,
> > yeah look, this is how it works. your table has x, y, and z.
> > you set up a mapper. x, y and z all become ColumnPropertys on
> > your mapper, without you doing anything, i.e. no properties dict.
> > if you set up a properties dict, columns which you map
> > explicitly will override the n
> > btw around probing dbcook on 0.4, i got some sort of statistical
> > idea of what is used often, some in a frightening repeatable
> > pattern:
> >
> > from sqlalchemy import *
> > db = create_engine('url')
> > meta = MetaData(db)
> >
> > and just then all else follows... in 90% of my files.
>
On 7/27/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> On Jul 27, 2007, at 4:03 PM, Gaetan de Menten wrote:
>
> >> so do you just want "explicit_columns=True" so that no auto-grabbing
> >> of columns occurs ?
> >
> > I don't know exactly what I want (or maybe it's just I don't care how
> > it'
On Jul 27, 2007, at 4:18 PM, Paul Johnston wrote:
> 1) Build python table definitions from a live database (i.e. AutoCode)
> 2) Tell you where a MetaData differs from a live database
> 3) Automatically build migrate scripts for simple database changes
> (e.g.
> adding a column)
>
> Now, I thin
On Jul 27, 2007, at 4:03 PM, Gaetan de Menten wrote:
>> so do you just want "explicit_columns=True" so that no auto-grabbing
>> of columns occurs ?
>
> I don't know exactly what I want (or maybe it's just I don't care how
> it's done). It's just that I found it suboptimal that in some cases
> th
is there any bool(x) construct there?
i guess the sqlcompiler can automaticaly replace any boolean x with
bool(x), or whatever...
On Friday 27 July 2007 23:27:37 Paul Johnston wrote:
> Hi,
>
> >type. Do you have some idea how to preserve entire boolean
> > semantics in mssql?
>
> I've not tried
On Friday 27 July 2007 19:48:51 Jonathan Ellis wrote:
> I'd want to make sure this didn't hurt performance first. (Seems
> innocuous enough, but if it's in any sort of inner loop the extra
> hash lookup might be noticeable.)
if lookup is made once in the start of function, should be okay.
which i
Hi,
>type. Do you have some idea how to preserve entire boolean semantics
>in mssql?
>
>
I've not tried this but perhaps comparing to 1 does the trick, e.g.
instead of "a and not b" do "(a = 1) and not (b = 1)"
Paul
--~--~-~--~~~---~--~~
You received this mess
Hi,
It's been great to see the recent discussions on this. An area I've been
meaning to do some more work on for a while. I've noticed there are two
main schools of thought on this issue:
1) Some people want the database layout to be completely defined in the
database and have the Python side
MSSQL is case-sensitive, and wants to see queries to INFORMATION_SCHEMA in
UPPER CASE.
See mssql.py.uppercase_table() for the gory details, or rather, THE GORY
DETAILS ;-)
On 7/27/07, Christophe de VIENNE <[EMAIL PROTECTED]> wrote:
>
>
> Hi svil,
>
> Still no luck. I don't know if the information
Hi,
>Still no luck. I don't know if the information_schema module is
>supposed to work well with pymssql. Anyway :
>
>
It works ok on Windows. Have a go at trying an information_schema query
directly in PyMSSQL, without using SA at all. That should settle the matter.
Paul
--~--~-~--~
On 7/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On Friday 27 July 2007 21:26:51 jason kirtland wrote:
> > svilen wrote:
> > > Anyway it may depend which audience are u targeting with these
> > > names - those who never seen an API or those for which names are
> > > important only to
On 7/27/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> On Jul 27, 2007, at 8:34 AM, Gaetan de Menten wrote:
>
> > First, it complained there was no alias, while I *think* aliases
> > should only be necessary when the query is used in a subquery, but
> > anyway, after giving it its alias, it st
On Friday 27 July 2007 21:26:51 jason kirtland wrote:
> svilen wrote:
> > Anyway it may depend which audience are u targeting with these
> > names - those who never seen an API or those for which names are
> > important only to associate them with a
> > library/version/use-case... both extremes
im more in favor of "Datasource", less so for Catalog. i still think
"Catalog" is vague, MetaData is a well known word and we can just
describe it really carefully as "MetaData is a catalog of
tables.". if you read fowlers book it *is* exactly what we are
using it as, its informatio
svilen wrote:
> Anyway it may depend which audience are u targeting with these
> names - those who never seen an API or those for which names are
> important only to associate them with a
> library/version/use-case... both extremes are equaly
> uninteresting imo.
I came around to thinking abou
Marco wrote:
>
> svilen ha scritto:
>
>> Anyway it may depend which audience are u targeting with these
>> names - those who never seen an API or those for which names
>> are important only to associate them with a
>> library/version/use-case... both extremes are equaly
>> uninteresting imo.
>>
I'd want to make sure this didn't hurt performance first. (Seems
innocuous enough, but if it's in any sort of inner loop the extra hash
lookup might be noticeable.)
On 7/27/07, svilen <[EMAIL PROTECTED]> wrote:
>
> one suggesstion / request.
>
> As your changing everything anyway, can u replace
On 7/26/07, jason kirtland <[EMAIL PROTECTED]> wrote:
>
> With 0.4 almost upon us, we're coming down to the wire for big changes
> getting in- and some things are kind of "now or never".
>
> I've found myself explaining engines and metadata with some particular
> language lately, and I wondered, w
patch would be helpful
On Jul 27, 2007, at 8:27 AM, svilen wrote:
>
> one suggesstion / request.
>
> As your changing everything anyway, can u replace all important {} and
> dict() with some util.Dict, and set() with util.Set?
> util.Ones can point to dict/set.
> The reason is so they can be fur
On Friday 27 July 2007 18:14:48 Michael Bayer wrote:
> On Jul 27, 2007, at 6:29 AM, avdd wrote:
> > On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote:
> >> This is the last opportunity
> >> for terminology changes for a while, so I offer this up for
> >> discussion.
> >
> > Does anyone
> So here's what I was thinking:
>
> datasource = create_datasource('posgresql:///test')
> connection = datasource.connect()
+0 -- I think it's moderately better than engine but for me, not
enough to want to change, though I wouldn't mind seeing it changed.
> catalog = Catalog()
> Table('foo',
On Jul 27, 2007, at 8:34 AM, Gaetan de Menten wrote:
> First, it complained there was no alias, while I *think* aliases
> should only be necessary when the query is used in a subquery, but
> anyway, after giving it its alias, it still doesn't work: I can't save
> any data. Worse, it doesn't comp
OK, first thing is that you should be using "backref" for this
relationship, it only helps.
But secondly is, you are actually *setting* the relationship here by
manipulating foreign key ids, which is usually not needed; the way to
manipulate relations between ORM instances is by attribute/c
On Jul 27, 2007, at 6:29 AM, avdd wrote:
>
> On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote:
>> This is the last opportunity
>> for terminology changes for a while, so I offer this up for
>> discussion.
>
> Does anyone else think "orm.relation" is wrong? Perhaps
> "relationship"
here the changes i needed to get dbcook (abstraction layer over SA),
and its tests going to some extent (70% - relations and expressions
are broken):
- BoundMetaData -> MetaData - lots (15)
- metadata.engine.echo=True - lots (14)
Whats the difference between create_engine's echo=boolean and
M
What popular misunderstanding would that be?
I have no problem with any of the terminology from S/A. It all seems
unambiguous, and makes sense.
Of course, I also studied database theory, relational algebra, and
relational calculus at university.
~jon
On Jul 27, 5:29 am, avdd <[EMAIL PROTECTED]
On Fri, 27 Jul 2007 04:36:50 -
Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> Hey ho -
>
> after around 400 revisions the 0.4 branch is merged to trunk:
>
> http://svn.sqlalchemy.org/sqlalchemy/trunk
Congratulations on the progress for the next generation! That goes for
you, Michael Bayer
Hi svil,
Still no luck. I don't know if the information_schema module is
supposed to work well with pymssql. Anyway :
Traceback (most recent call last):
File "autoload.py", line 233, in ?
autoloader = AutoLoader( engine)
File "autoload.py", line 100, in __init__
me.table_names = engi
On 27 Lip, 05:45, "King Simon-NFHD78" <[EMAIL PROTECTED]> wrote:
> The problem is that when you run your last query, SA sees that there is
> still an existing T1 object (with the right primary key) in memory (both
> in the session and in your 'a1' and 'ra1' variables). It deliberately
> doesn't up
On Jul 27, 7:32 am, "King Simon-NFHD78" <[EMAIL PROTECTED]>
wrote:
> You want something like this:
>
> user_table = Table('users', metadata, Column('userid', String(8)))
> user_table.create(checkfirst=True)
> # or
> # metadata.create_all(checkfirst=True)
>
> Documentation is at:
>
> http://www.sql
The problem is that when you run your last query, SA sees that there is
still an existing T1 object (with the right primary key) in memory (both
in the session and in your 'a1' and 'ra1' variables). It deliberately
doesn't update them.
To get the behaviour you expect, you need to get rid of previ
On 27 Lip, 05:30, svilen <[EMAIL PROTECTED]> wrote:
> i think u should not make 2 separate relations, but one relation on
> one of the tables, with a backref to the other.
> i.e. just
> mapper( T1, t1, properties={"t2s": relation(T2, lazy=False,
> backref='t1')})
> do check doco, just in case.
N
Hi,
I'm trying SA with MS SQL Express 2005 (Linux, pymssql, freeTDS).
there is an issue with NOT, AND, OR operators of mssql. the SQLAlchemy
translates Boolean type to MSSQL BIT data type, but... NOT on
something_of_BIT_Datatype produces error. It is stated in the msdn
that NOT, AND, OR work onl
Hi all,
The way single table inheritance works seem a bit "unclean" to me: all
columns are available as properties in all classes. Even if they map
to the same table, ideally each object should only have a subset of
columns available, right? SQLAlchemy can't guess which object has
which columns, s
i think u should not make 2 separate relations, but one relation on
one of the tables, with a backref to the other.
i.e. just
mapper( T1, t1, properties={"t2s": relation(T2, lazy=False,
backref='t1')})
do check doco, just in case.
On Friday 27 July 2007 15:07:39 Michal Nowikowski wrote:
> Hel
You want something like this:
user_table = Table('users', metadata, Column('userid', String(8)))
user_table.create(checkfirst=True)
# or
# metadata.create_all(checkfirst=True)
Documentation is at:
http://www.sqlalchemy.org/docs/metadata.html#metadata_creating
Hope that helps,
Simon
> -O
one suggesstion / request.
As your changing everything anyway, can u replace all important {} and
dict() with some util.Dict, and set() with util.Set?
util.Ones can point to dict/set.
The reason is so they can be further globally replaced by user with
OrderedOnes, for example to achieve repeat
I've looked and looked, but can't find any guidance on this. I want a
program that, the first time it's run, creates its tables. I'm
guessing that I need something like this:
try:
user_table = Table('users', metadata, autoload=True)
except NoSuchTableError:
user_table = Table('users', metad
Hello
I've following problem. I've two tables (t1, t2) and relation t1 (one)
- t2 (many):
mapper(T1, t1, properties={"t2s": relation(T2, lazy=False)})
mapper(T2, t2, properties={"t1": relation(T1, lazy=False)})
When I add row to t1, then to t2, and then run query for first row in
t1, I see o
On Friday 27 July 2007 12:44:49 Christophe de VIENNE wrote:
> 2007/7/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > noone wanting to try autoload'ing nor metadatadiff? i am
> > surprised.. Christophe, u can at least try how much autoload.py
> > works like your autocode2 - i got lost with 'schema'
On Jul 27, 9:45 am, jason kirtland <[EMAIL PROTECTED]> wrote:
> This is the last opportunity
> for terminology changes for a while, so I offer this up for discussion.
Does anyone else think "orm.relation" is wrong? Perhaps
"relationship" if you must have a noun, or "relates_to", etc, but
"relati
svilen ha scritto:
> Anyway it may depend which audience are u targeting with these names -
> those who never seen an API or those for which names are important
> only to associate them with a library/version/use-case... both
> extremes are equaly uninteresting imo.
>
I think targeting tho
2007/7/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> noone wanting to try autoload'ing nor metadatadiff? i am surprised..
> Christophe, u can at least try how much autoload.py works like your
> autocode2 - i got lost with 'schema' vs 'dbname' - and/or add mysql
> support (;-)
I tried to run it on
On Friday 27 July 2007 11:44:43 Gaetan de Menten wrote:
> On 7/27/07, svilen <[EMAIL PROTECTED]> wrote:
> > On Friday 27 July 2007 02:45:12 jason kirtland wrote:
> >
> > - Catalog:
> > what is a sqlalchemy's metadata?
> >
> > >jason> "a catalog of tables available in the database."
> >
> > to me
On 7/27/07, svilen <[EMAIL PROTECTED]> wrote:
> On Friday 27 July 2007 02:45:12 jason kirtland wrote:
> - Catalog:
> what is a sqlalchemy's metadata?
> >jason> "a catalog of tables available in the database."
> to me it holds everything about the "subset of database structure",
> used in the app
On Friday 27 July 2007 02:45:12 jason kirtland wrote:
> So there you have it. I'm not married to this proposal by *any*
> means. The ideas gelled in my brain during the SQLAlchemy tutorial
> at OSCON, and this seems like the last opportunity to deeply
> question and reconsider what we have before
52 matches
Mail list logo
