Hi Jorge,
Thank you very much for your informative post!
> After reading this it actually isn't that crazy :) I also have had the
> issue of using the config on module loading. Where you able to run the
> test suite to this and things work fine? I'll love to see a patch so
> we can test it. If it has no side effects I think it's the way to go.
> Config should be available everywhere.
I don't know the TG2 internals _at all_, so you can imagine why I have
been concerned that mucking around with the quickstart generated
templates might result in Bad Things.
Here's the nosetests from the quick app I set up to test these changes:
'''
(tg2)[sagittarius:TestAuth]$ nosetests
/home/bshelton/projects/python/tg2/lib/python2.5/site-packages/SQLAlchemy-0.5.1-py2.5.egg/sqlalchemy/engine/default.py:229:
SAWarning: Unicode type received non-unicode bind param value
'manager'
param.append(processors[key](compiled_params[key]))
...../home/bshelton/projects/python/tg2/lib/python2.5/site-packages/SQLAlchemy-0.5.1-py2.5.egg/sqlalchemy/engine/default.py:229:
SAWarning: Unicode type received non-unicode bind param value 'editor'
param.append(processors[key](compiled_params[key]))
............
----------------------------------------------------------------------
Ran 17 tests in 3.412s
OK
'''
There are probably other tests that should be run, but I have no idea
which or where to start with those. Any pointers would be more than
welcome!
I did neglect to mention (it was late my time!) in my last reply that
I had to add the following to my model modules to update the
configuration object:
'''
from tg import config
from testauth.config.local_config import locals
config.update(locals)
'''
But I think that's mostly an incidental change and can be dealt with
elsewhere. I could've also just used the global configuration data
stowed away as I mentioned before.
> Right now you should be able to do something like this.
>
> def yourCustomConstructor(self, **kwargs):
> self.__tablename__ = config.get("database.table.prefix") +
> self.__tablename__
> _declarative_constructor()
>
> DeclarativeBase = declarativeBase(constructor=yourCustomConstructor)
Thinking back on it, this is a question I really should have directed
to the SA list instead. I've been lurking both for a while now, and it
seemed to me that the TG crowd has a much broader understanding of
various applications of the individual projects TG uses, including a
great deal of esoteric and unusual knowledge. This seemed like the
logical place to ask, particularly since my problem was more one of
accessing the configs from unusual places.
As an aside, when I was doing some research on table prefixes in
SQLAlchemy I ran across a couple of wrapper projects that implemented
the functionality. I don't recall how they did it, but I'm going to
take another look.
Oh! One more thing along these lines: I discovered that if the
configuration object is available when declaring the model, you can do
strange things such as tailoring vendor-specific types to the
underlying database:
'''
bigindextype = Integer
driver = locals["sqlalchemy.url"][ 0 :
locals["sqlalchemy.url"].find(":") ] # Could probably ask the metadata
object what driver it's using here instead, but I didn't have much
luck.
# Optionally, config.get("sqlalchemy.url") would work, too.
if driver == 'mysql':
# Vendor specific cruft.
from sqlalchemy.databases.mysql import MSBigInteger
bigindextype = MSBigInteger
# Define tables using ``bigindextype`` as the integer type if you
# have a fear that they may exceed MEDIUMINT's limits for MySQL.
'''
This is probably useless, but I may have a need for using certain
vendor-specific cruft in the future. I also like the idea of using the
PGInet type for PostgreSQL if that's the DB of choice.
> Since this is a very common use case (at least from people coming from
> the php world) I think the ideal solution will be to have
Funny thing is, this is almost exactly my scenario and also why table
prefixes were something of a necessity for me. I'm sick of PHP for
personal projects and have been eyeing TG off for quite a few months
now, and Python is a much nicer language on the eyes. I still do
maintenance from time to time on PHP-related sites running a very
popular message board software, but frankly, finding well-written PHP
is next to impossible even in commercial packages. I'm thinking TG can
help me retain what sanity I have left. :)
Thanks for all the help, Jorge!
--
Regards,
Benjamin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
