ive checked in a gigantic amount of code related to default column
values.
You now can create defaults on columns in several ways:
t = Table('mytable', engine,
# literal, in code. this default will be created in Python and
inserted
Column('col1', Integer, default="3")
# function - this default will be run in Python and inserted
Column('col2', Integer, default=lambda: "im a default")
# SQL expression - this expression will be pre-executed and inserted
Column('col3', Date, default=func.current_date()),
# SQL-side default, can take a function (postgres/oracle)
Column('col4', Date, PassiveDefault(func.current_date())
# or a literal string - put quotes around all of them (the string
can only contain an integer number in mysql)
Column('col5', String, PassiveDefault("im a default"))
)
Unit test: test/query.py --db <sqlite|mysql|postgres|oracle>
QueryTest.testdefaults
If the ORM inserts a row that contains PassiveDefaults, the engine
will return this fact and the ORM will post-fetch the row and update
the properties of the newly inserted object.
Unit test: test/objectstore.py --db <sqlite|mysql|postgres|oracle>
DefaultTest
On Jan 27, 2006, at 9:15 AM, Nicholas Wieland wrote:
On 1/27/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
On Jan 26, 2006, at 8:01 PM, Nicholas Wieland wrote:
Serial in fact is a an int(4) type with a default to nextval
(table_column_seq):
Test=# \d Test
Table "public.test"
Column | Type |
Modifiers
--------+-----------------------------
+---------------------------------------------------
id | integer | not null default
nextval('test_id_seq'::regclass)
You can fetch this information with
Test=# select column_default from information_schema.columns where
column_name='id';
column_default
----------------------------------
nextval('test_id_seq'::regclass)
(1 row)
IMHO using default is the best option
OK, if i did some thing to parse out the "default" from that, it
wouldnt be "SERIAL", it would just be a default object with the value
sitting inside of it (also what is ::regclass, does that have to be
filtered out ?).
Yes, so develeopers just have to parse out the default value, exactly
as in Postgres.
I think you can filter regclass, because I suspect it's a >8.0 feature
(I'm not sure though).
In >8.0 it works without problems:
Test=# select nextval ('test_id_seq'::regclass) from test_id_seq;
nextval
---------
4
(1 row)
Test=# select nextval ('test_id_seq') from test_id_seq;
nextval
---------
5
(1 row)
Also, when you go to INSERT a row, SA is giong to
explicitly run all the defaults as separate queries beforehand, as
opposed to letting the database run them automatically, since thats
what a "default" does. the explicit behavior is needed for at least
the primary key columns, as they are often needed right after INSERT
(and with rowids turned off, postgres/psycopg gives you no way of
getting at a recently inserted row otherwise). it could be modified
for non-primary-key columns to not run the default explicitly
beforehand....any opinions ?
IMHO it's perfect to always run the default, because the only reason
to use SERIAL is to have a unique identifier inside a record. I can't
see any reason to explicitly use something different than the default
value, a sequence is sequence ...
ngw
p.s. sorry, i forget to Cc my mails to the list, as usual.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
