Yes, of course. ;-) But is it possible not to map certain columns?
Preferably, without using a select and listing every single column
that should be present?
Foreign key columns are obvious candidates to be left out, because the
relations should be used instead. Currently, I always rename them
If I would make a select with a field set to a constant like this:
SELECT 1 AS field FROM foo
how is the select()'s field definition ? I'v tried with:
select([1], from_obj=[foo])
but field has no name.
--~--~-~--~~~---~--~~
You received this message because
On Jul 3, 5:26 am, klaus [EMAIL PROTECTED] wrote:
Yes, of course. ;-) But is it possible not to map certain columns?
Preferably, without using a select and listing every single column
that should be present?
well not including those columns in the selectable is the easiest way
to do this.
Expo ha scritto:
If I would make a select with a field set to a constant like this:
SELECT 1 AS field FROM foo
how is the select()'s field definition ? I'v tried with:
select([1], from_obj=[foo])
but field has no name.
select([1 as bar], from_obj=[foo])
Glauco
--
select([literal(1).label(field)], from_obj=[foo])
or to not use the bind param
select([literal_column(1).label(field)], from_obj=[foo])
On Jul 3, 9:32 am, Expo [EMAIL PROTECTED] wrote:
If I would make a select with a field set to a constant like this:
SELECT 1 AS field FROM foo
how is
Great. This gives us a very good reason to shift everything we have
to Pylons. I like the fact that Pylons gives us that controller as I
think that control is very important in developing a robust
application. I want to know what goes one versus having the framework
do everything for me.
Hi,
Oh, you're running on Linux. pymssql is probably your best bet, but you
can still expect lots of things to break. SA/MSSQL is now pretty solid
on Windows, perhaps that's an option for you.
Paul
fw wrote:
Thanks Paul for your answer
but
I was using pymssql.
Now, I am trying to use
Hi Mike,
Your proposal sounds pretty sensible, in fact I don't use most of those
features. Just one concern:
2. assignmapper query methods
Are the basics like select and select_by still going to be available
directly? I hope so, as I use them extensively.
Paul
Thank you very much, Michael.
It was very clear and helpful and help set my mind straight on the
issue.
One of the things that confused me was the term optimistic
locking (used elsewhere, not by yourself).
In the optimistic approach, there is no locking at all.
On Jul 1, 11:28 pm, Michael Bayer
What is the correct documentation for it?
The docs say it returns the primary key but for now I see it returns
an auto increment field (which is not part of the key).
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
I managed to avoid this issues because for select and insert I can use
dictionaries as arguments of execute().
For update, I must create a where clause from a list of conditions I
have as a dictionary.
How do I do this programatically?
--~--~-~--~~~---~--~~
You
On Jul 3, 2:36 pm, Paul Johnston [EMAIL PROTECTED] wrote:
Hi Mike,
Your proposal sounds pretty sensible, in fact I don't use most of those
features. Just one concern:
2. assignmapper query methods
Are the basics like select and select_by still going to be available
directly? I hope so,
On Jul 3, 4:01 pm, mc [EMAIL PROTECTED] wrote:
What is the correct documentation for it?
The docs say it returns the primary key but for now I see it returns
an auto increment field (which is not part of the key).
I doubt thats true. but also, this function has been reworked to be a
lot
On Jul 3, 4:06 pm, mc [EMAIL PROTECTED] wrote:
I managed to avoid this issues because for select and insert I can use
dictionaries as arguments of execute().
For update, I must create a where clause from a list of conditions I
have as a dictionary.
How do I do this programatically?
Michael Bayer [EMAIL PROTECTED] writes:
4. global_connect() / default_metadata
(...)
(...) Plus it used DynamicMetaData which
is a totally misunderstood object that isnt going away but will be
much more downplayed. youre responsible for your own MetaData
jason kirtland [EMAIL PROTECTED] writes:
DynamicMetaData is not deprecated, but it may be renamed in 0.4 to
clarify its role. For this setup, a MetaData will suffice- it is
dynamic as in late binding and re-bindable. After you get your
engine sorted out, you can connect() the engine and
On Jul 3, 10:00 pm, David Bolen [EMAIL PROTECTED] wrote:
In re-reading the documentation with your comments in mind, it's clear
that the docs do mention connecting a normal MetaData object, but the
examples (and those in the source tree) tend to use BoundMetaData or
DynamicMetaData, so I
17 matches
Mail list logo
