Re: [sqlalchemy] Tips for schema based db traversal and building

2015-09-09 Thread Steve Murphy
Oh, Michael!

You have made my day. It just gets better and better!

I don't know how I missed these items, but your examples are very helpful.

Many thanks!


On Tuesday, September 8, 2015 at 7:00:12 PM UTC-6, Michael Bayer wrote:
>
>
>
> On 9/8/15 12:57 PM, Steve Murphy wrote:
>
>
> A bit difficult is grabbing just certain columns in the select, given
> that we have only a list of column names. That would be real nice
> if such a method were available in the core API.
>
> For example, a method for select whereby I could supply a simple
> list of column names to fetch in the select would be very handy:
>
> tablename = "user"
> tab = meta1.tables[tablename]
> collist = [ "id", "name", "address" ] ## just a few of many more
> q = tab.select(colnames=collist)
>
> this is pretty simple:
>
> q = select([tab.c[name] for name in ["id", "name", "address"]])
>
> Also, if I could get a column object from a table by name
> it would really make life easier at times:
>
> q = select([tab]).where(tab.colname(colnamevar) == col_var_val)
>
>
> yeah, tab.c[name]
>
> this is here:
>
>
> http://docs.sqlalchemy.org/en/rel_1_0/core/metadata.html#accessing-tables-and-columns
>
>
>
> Another rough spot with the API is setting up a simple set of where
> clauses for a select, given a map of column names vs. values.
> if the map contained {"user": "cat", "city": "Gotham"} it would
> be cool if we could get the desired select:
>
> select * from table where user='cat' and city='Gotham';
>
>
> that is:
>
> select = select.where(and_(*[tab.c[key] == value for key, value in 
> mymap.items()]))
>
>
> Another rough spot is getting a list of constraints. I note that
> postgresql has sql to create constraints, and remove them, but
> not to get a list of them. 
>
> you can get these like this:
>
> from sqlalchemy import inspect
> insp = inspect(my_engine)
>
> fk_constraints = insp.get_foreign_keys('mytable')
> uq_constraints = insp.get_unique_constraints('mytable')
> indexes = insp.get_indexes('mytable')
>
> docs: 
> http://docs.sqlalchemy.org/en/rel_1_0/core/reflection.html#fine-grained-reflection-with-inspector
>
> there's no listing of CHECK constraints right now.
>
> they are also available on the Table as fully constructed constraint 
> objects:
>
> table = Table('mytable', somemetadata, autoload=True)
> for constraint in table.constraints:
> #   ...
>
>
> docs for the table.constraints accessor are not in good shape right now, 
> the API docs aren't generating for it and there's only a few mentions of 
> it, but inspector is usually more straightforward if you are just getting 
> raw information about them.
>
>
>
> I do see the "\d " command,
> and you get a list of all the foreign keys and constraints that way,
> all in a big block of text I'm sure that, without supporting sql 
> syntax,
> any further sqlalchemy constraint support will be very hard, if not 
> impossible,
> to implement.
>
> well \d is just part of your psql shell, it is ultimately querying the 
> pg_catalog tables which is what the SQLA postgresql dialect queries as well.
>
>
>
> The fact that sqlalchemy does what it does has saved me a ton of time 
> writing
> a full-blown SQL parser. Many congrats, thanks, ataboys,  and kudu's!!!
>
>
> thanks glad its working out!
>
>
>
> murf
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sqlalchemy+...@googlegroups.com .
> To post to this group, send email to sqlal...@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


[sqlalchemy] get_schema_names doesn't work with SQLite attached databases

2015-09-09 Thread Van Klaveren, Brian N.
Hi,

I'm trying to find the attached databases of a SQLite database. I was expecting 
Inspector.get_schema_names to return something like:


$ sqlite3 foo.db
sqlite> create table a (a_id integer);

sqlite3 bar.db
sqlite> create table b (b_id integer);


from sqlalchemy import create_engine
from sqlalchemy.inspection import inspect

engine = create_engine("sqlite://", echo=True)

engine.execute("attach database 'foo.db' as foo")
engine.execute("attach database 'bar.db' as bar")

refl = inspect(engine)

refl.get_table_names(schema="foo") # works
refl.get_table_names(schema="bar") # works

refl.get_columns("a", schema="foo") # works
refl.get_columns("b", schema="bar") # works

refl.get_schema_names() # doesn't work, returns []



It doesn't seem the SQLite dialect supports this, but it does seem like the 
SQLite dialect could support this via the equivalent of this:


@reflection.cache
def get_schema_names
dl = connection.execute("PRAGMA database_list")
return [r[1] for r in dl]


Is this reasonable? Could it be included in the SQLite dialect?

Brian

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.


Re: [sqlalchemy] get_schema_names doesn't work with SQLite attached databases

2015-09-09 Thread Mike Bayer



On 9/9/15 4:59 PM, Van Klaveren, Brian N. wrote:

Hi,

I'm trying to find the attached databases of a SQLite database. I was expecting 
Inspector.get_schema_names to return something like:


$ sqlite3 foo.db
sqlite> create table a (a_id integer);

sqlite3 bar.db
sqlite> create table b (b_id integer);


from sqlalchemy import create_engine
from sqlalchemy.inspection import inspect

engine = create_engine("sqlite://", echo=True)

engine.execute("attach database 'foo.db' as foo")
engine.execute("attach database 'bar.db' as bar")

refl = inspect(engine)

refl.get_table_names(schema="foo") # works
refl.get_table_names(schema="bar") # works

refl.get_columns("a", schema="foo") # works
refl.get_columns("b", schema="bar") # works

refl.get_schema_names() # doesn't work, returns []



It doesn't seem the SQLite dialect supports this, but it does seem like the 
SQLite dialect could support this via the equivalent of this:


 @reflection.cache
 def get_schema_names
 dl = connection.execute("PRAGMA database_list")
 return [r[1] for r in dl]


Is this reasonable? Could it be included in the SQLite dialect?

sure, send a PR and we can have this in 1.1.






Brian



--
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.