On Monday 29 December 2008 13:31:02 Michael Bayer wrote:
[...]
There are already a lot of tools that build forms and such based on
tables which use the existing reflection capabilities, so what's
currently available is probably sufficient for your needs.
Michael,
Do you by any chance have a
sure we have:
http://code.google.com/p/dbsprockets/
http://code.google.com/p/formalchemy/
http://www.sprox.org/
to be fair, sprox seems to be a reorganization of dbsprokets.
On Jan 1, 2009, at 6:36 PM, Nicolas Echaniz wrote:
On Monday 29 December 2008 13:31:02 Michael Bayer wrote:
[...]
Randall's work with reflection is targeted for the 0.6 series. the
focus of 0.6 so far is a refactor of engine/dialect organization so
that's the best place to put his new features. Work has already
started and it will be most of what we're working on once 0.5 is
released, which
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
On Nov 10, 2008, at 2:25 AM, Randall Smith wrote:
Just to make sure we're considering the same plan, I don't plan to
make
any API changes that would cause breakage. All changes are additions
including the public API and some new dialect methods (get_views,
get_indexes, ...). Most of
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 dialect sooner rather than
On Nov 7, 2008, at 11:13 PM, Randall Smith wrote:
reflecttable is very monolithic. Breaking it down into smaller
components will make it easier to test. I follow you on adding
methods
to the Dialects and that seems like a good place for them.
I don't know
what kind of API
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
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
On Nov 7, 2008, at 1:46 PM, Randall Smith wrote:
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
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
eh, when all these attempts will be combined...
here's mine: use as u can
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
12 matches
Mail list logo
