Am Freitag, 14. September 2007 23:52 schrieb jason kirtland:
Hermann Himmelbauer wrote:
Hi,
In one of my database tables I have a varchar that is mapped to an object
with a string attribute. This specific varchar should however be
represented by a certain Python object, therefore it
Has anyone added support for the POLYGON data type in PostgreSQL? If
so, is there any code that can be shared?
-Mark
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send
Hi,
I am creating my database via SQLAlchemy, therefore I use several Column()
objects in a Table() clause.
For my documentation, it is very handy to gather the table definitions
directly from my SQLAlchemy-based python code - that's relatively easy, I
simply import my table-definitions file
On Sep 17, 5:03 am, [EMAIL PROTECTED] wrote:
Has anyone added support for the POLYGON data type in PostgreSQL? If
so, is there any code that can be shared?
I haven't seen POLYGON but the beginnings of such support is over at
bycycle.org[1]. I'm interested in something similar for MySQL's
suggestions:
on the descriptions... maybe right now u can inherit Columns and
Tables and whatever by your own classes adding the .descriptions
passing all else down.
on the table-gathering, instead of python-parsing, u could just use
the metadata and walk it - it will have all your tables,
I've started using add_column() as needed to work around this. Our application
tends to have a single, fairly generic filter_sort function for each class.
Some use cases of this function require add_column() and some don't. From the
caller's perspective, the filter_sort() function is poorly
On Sep 17, 3:03 pm, [EMAIL PROTECTED] wrote:
Has anyone added support for the POLYGON data type in PostgreSQL? If
so, is there any code that can be shared?
Here's a patch implementing PGPolygon. The conversion from/to python
types should be done in dbapi IMHO (i.e. psycopg2) but this will work
sc0ttbeardsley wrote:
On Sep 17, 5:03 am, [EMAIL PROTECTED] wrote:
Has anyone added support for the POLYGON data type in PostgreSQL? If
so, is there any code that can be shared?
I haven't seen POLYGON but the beginnings of such support is over at
bycycle.org[1]. I'm interested in something
i don't have recent py-gis experience, but from past, its been
tuple-likes and numpy arrays. Best option will be to have some
default data-representation constructor for each SA-GIS type, and
allow overriding that.
e.g. Point holds data by default in a tuple (Point.DataHoler=tuple),
but i can
see some notes at
http://www.sqlalchemy.org/trac/wiki/DatabaseNotes
also check dbcook.usage.sa_engine_defs.py at
(svn co)
https://dbcook.svn.sourceforge.net/svnroot/dbcook/trunk/dbcook/usage/
for some create/drop stuff, both pyodbs/pymssql.
3. I'll be piggy backing on an existing ERP system
Hi Alchemists,
I am starting a project in Pylons that will need to access a MSSQL
database. I plan to develop on Windows and deploy on Linux. It sounds
like pyodbc is the best option and that it is reasonably well
supported. I've done a lot of Google searching but I haven't been able
to find
On Sep 14, 2007, at 3:52 PM, Rick Morrison wrote:
I think it might be more historical than anything else. Back when
what is now filter() was a single argument to the select() call, on
the SQL-API side, and there couldn't take any additional arguments,
as the select() call was already
On Sep 15, 2007, at 5:10 PM, Ryan wrote:
And whatever happened to the nice select_by Query method where I could
mix filter-type criterion arguments and filter_by-type keyword
arguments in one call. *That* was readable to me, and very usable in
a pythonic way. What's wrong with having one
Hi Scott,
...to develop on Windows and deploy on Linux. It sounds
like pyodbc is the best option
pyodbc works well in Windows, but I've heard on Linux, not so much. pymssql
is your best bet for Linux. Note that pymssql does not work with unicode,
limits SQL identifiers to 30 characters, and
14 matches
Mail list logo
