maxi wrote:
Hi,
Are there any approach to get columns names from query result ?
I'm executing a dynamic sql statemet using text function and execute.
s = 'select * from foo where foo.name like = :name'
txt = text(s, bind=database.metadata.bind)
p = {'name':u'some name'}
result =
PacSci wrote:
Hi.
After working out my metadata issues (and scrapping four revisions and
a Tomboy notepad of plans for my framework), I've realized that I am
going to need something that is like FormAlchemy, but will convert
models to a WTForms form instead. I've got the basis of the form
I've been working on breaking Dialect.reflecttable into components so
that they can be used independently (e.g. get_columns, get_foreign_keys,
etc). One of the original goals was to be able to do away with
reflecttable and have the Inspector, engine.reflection.Inspector,
construct the table
, most of the dialects might use
DefaultDialect.reflect_columns and so on.
So for now, I'll leave that idea alone and move on to refactoring the
rest of the dialects.
--Randall
Randall Smith wrote:
I've been working on breaking Dialect.reflecttable into components so
that they can be used
I would put the addCustomer method on something other than the customer
object, like the thing you're adding the customer to. Or bettery yet,
you'd probably be just appending the customer. I think for your
specific example, you should handle customer creation stuff (login +
password) in
Paul Johnston wrote:
Hi,
eng =
sqlalchemy.create_engine(mssql:///?dsn=mydsn,UID=myusername,PWD=mypass,module=pyodbc)
Try this:
eng =
sqlalchemy.create_engine(mssql://myusername:mypass@/?dsn=mydsn,module=pyodbc)
Paul
You shouldn't need to define a dsn. This should work:
Rick Morrison wrote:
That's great news, and we're glad for the help. What version of MSSQL
will you be working with?
2005 currently. I hope to get access to other versions though.
Randall
--~--~-~--~~~---~--~~
You received this message because you are
Lukasz Szybalski wrote:
On Mon, Mar 31, 2008 at 9:53 AM, Rick Morrison [EMAIL PROTECTED] wrote:
So what you are saying here is that sqlalchemy will figure out what driver
to use? pyodbc or other?
Sort of. Attempts are made to import appropriate modules until one doesn't
fail. The order is:
To my knowledge, there doesn't exist a tool to extract schema
information from a database with a database independent API. SA does
this to some extent by providing table_names and reflectable methods
on it's Engine class, but I think it would be nice to have something
more comprehensive and
If anyone wants to toy with this, I posted it here for the meantime.
Works with Postgresql and MSSQL for schema_names, table_names,
constraints (including foreign keys) and columns.
http://www.tnr.cc/dbinfo.py
--Randall
--~--~-~--~~~---~--~~
You received this
Michael Bayer wrote:
We did long ago attempt to build an information schema API, which
was based on the information schema specification, before realizing
that this model hardly works in any current RDBMS (for example, its
excruciatingly slow on postgres) and is entirely inconsistent
Michael Bayer wrote:
The structure of the API would drive the current reflection API to
become more componentized. What we see as a need on the public
refleciton API side would drive the currently monolithic reflection
methods to be changed. The current reflecttable() methods in turn
Michael Bayer wrote:
You're on the right track. The reflection methods are always called
with a Connection that is not shared among any other thread
(connections aren't considered to be threadsafe in any case) so
threadsafety is not a concern.
I think you should look at the mysql
Michael Bayer wrote:
just FTR, the current expected behavior of default schemas is that if
your tables are known to exist in the default schema configured on the
database connection, you leave the schema attribute on Table blank.
otherwise, you set it.
The mssql dialect does not ask the
Michael Bayer wrote:
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Ticket 1258
-Randall
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this
Michael Bayer wrote:
so if we can confirm this ! .socloseto...release
From grepping:
For the Oracle dialect get_default_schema_name is used in reflecttable,
has_table and has_sequence. has_table, in turn, is used by the
SchemaGenerator and SchemaDropper.
MSSQL
that to SA, maybe through a plugin?
I'd be happy
to contribute if this is seen as valuable addition, I must add
though that
because we solely use postgres, I won't be able to add support for
anything
beyond that - but maybe others would step up to integrate other
engines.
Randall Smith
SA, without a transaction in progress will call commit on the database
connection when it detects an INSERT, UPDATE, DELETE, CREATE, etc. This
is it's autocommit mode. The relevant code is:
if context.should_autocommit and not self.in_transaction():
self._commit_impl()
Jon Nelson wrote:
An alternate solution is to use begin rollback for statements that
(aren't supposed to) update data, like (most) select statements.
That's even cheaper than calling commit usually.
There is no begin method in the DBAPI. You could call rollback instead
of commit, but I
Michael Bayer wrote:
I think with your project specifically, that of reading lots of
information during a reflection process given a single Connection, we
probably want to look into establishing transactional boundaries for
the reflection process, because in that case you do have the
Is there a way to inherit more than one level for single table
inheritance? Take this relationship for example:
Animal - Dog - German Shepard
Say there are 10 animals; 5 are dogs and 2 are German Shepard.
session.query(Animal).select() # Should yield 10 results.
Michael Bayer wrote:
On Nov 2, 2006, at 11:47 PM, Randall Smith wrote:
Is there a way to inherit more than one level for single table
inheritance? Take this relationship for example:
Animal - Dog - German Shepard
Say there are 10 animals; 5 are dogs and 2 are German Shepard
I touched on this in an earlier thread, but think it deserves its own.
The current inheritance implementation requires a column specified for
polymorphic_on passed to a mapper and a value for that column specified
for each inheriting mapper. I don't think this approach is flexible
enough and
Michael Bayer wrote:
just FYI, the type column idea is taken from Hibernate, and that's
all Hibernate supports as far as polymorphic loading.
I think it's good that SA takes good features from and is similar to
Hibernate, but I hope that your aspirations and those of SA's users are
to make
I've attached a file which is a variant to the employees example with
two objectives.
1. Base polymorphic_identity on select criteria (no type column).
2. Use two levels of inheritance.
The first objective seems to be met, but the second is not working
properly. I put in two Managers, two
John,
Thanks for the feedback. The code I put up is not part of any real
system. I'm just playing off of the existing examples in the docs and
trying to get comfortable with SA inheritance.
Randall
John M Camara wrote:
Randall Smith wrote:
For discussion, consider the Employee, Manager
dmiller wrote:
Is there a reason why this doesn't work:
orders = Table('orders', meta,
Column('id', Integer, Sequence('order_id_seq'), primary_key=True),
...
)
items = Table('items', meta,
Column('id', Integer, Sequence('item_id_seq'), primary_key=True),
I worked on this some more and found that the queries are correct as
they are. The problem is in the mapping. A Chemical Engineer is an
Engineer, who is an Employee. So the employees selectable should return
all employees and the engineer selectable should return all engineers,
not just
As I've been experimenting with inheritance, I think my hang ups are
largely due to my lack of understanding of how SA accomplishes it. So
here are some simple questions.
1. What does it mean for a mapper to inherit from another mapper? What
does it inherit from that mapper and how does
Michael Bayer wrote:
I should learn to explain better what syncrules are about, so heres
an attempt:
when you have a table A and a table B, and then a mapping relationship
between A and B, theres a join condition set up between the two tables.
By default, it draws from the foreign keys of
Responding to myself. As I wrote the first message, I started thinking
how just deleting the FK after metadata.create_all() wouldn't be so bad
and now I think that's a pretty good solution.
Randall
Randall Smith wrote:
Michael Bayer wrote:
I should learn to explain better what syncrules
This is the error: Note that the first param is an SA object instead of
the integer key.
sqlalchemy.exceptions.SQLError: (ProgrammingError) can't adapt 'SELECT
records_tinwsys.tinwsys_st_code AS records_tinwsys_tinwsys_st_code,
records_tinwsys.tinwsys_is_number AS
Never mind. My mistake. --Randall
Randall Smith wrote:
This is the error: Note that the first param is an SA object instead of
the integer key.
sqlalchemy.exceptions.SQLError: (ProgrammingError) can't adapt 'SELECT
records_tinwsys.tinwsys_st_code AS records_tinwsys_tinwsys_st_code
With this relationship
Record.mapper = sa.mapper(Record, records,
properties={
'tinwsys' : sa.relation(Tinwsys, secondary=records_tinwsys,
backref=sa.backref('efile_records')
}
)
SA is deleting associated records in records_tinwsys when a
I'm wondering what is the best way for a mapped object to acquire a
connection for a non-ORM style query while staying within the context
(reuse connection or transaction) of its own session. For example, here
is a method of a mapped object.
@property
def analysis_count(self):
Typo in untested example. session should be sess.
Randall
Randall Smith wrote:
I'm wondering what is the best way for a mapped object to acquire a
connection for a non-ORM style query while staying within the context
(reuse connection or transaction) of its own session. For example, here
36 matches
Mail list logo
