| 00:00.16 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 02:39.33 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 03:26.01 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
| 03:31.45 | *** join/#storm jamesh__ (n=james@canonical/launchpad/jamesh) |
| 06:20.53 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 06:50.06 | *** join/#storm dobee (n=dobeee@85-124-200-100.static.xdsl-line.inode.at) |
| 07:02.50 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 07:26.36 | *** join/#storm s1m (i=Kitt@cpe-076-182-054-107.nc.res.rr.com) |
| 07:27.30 | *** part/#storm s1m (i=Kitt@cpe-076-182-054-107.nc.res.rr.com) |
| 08:12.37 | *** join/#storm dobee (n=dobeee@lsfw01.lovelysystems.com) |
| 08:14.07 | *** join/#storm dobee (n=dobeee@lsfw01.lovelysystems.com) |
| 09:09.15 | *** join/#storm raazende (n=raazende@59.90.16.126) |
| 09:10.09 | *** part/#storm raazende (n=raazende@59.90.16.126) |
| 09:31.04 | *** join/#storm mcella (n=michele@ip-178-231.sn2.eutelia.it) |
| 13:52.16 | *** join/#storm niemeyer (n=niemeyer@200-181-139-239.ctame705.dsl.brasiltelecom.net.br) |
| 17:13.52 | *** join/#storm jkakar (n=jkakar@204-174-36-245.unknown-dhcp802.dsl.ucc-net.ca) |
| 18:00.24 | *** join/#storm dobee (n=dobeee@85.124.200.100) |
| 18:25.13 | *** join/#storm bradallen (n=bradalle@69.15.123.154) |
| 18:27.52 | bradallen | Hello...can anyone tell me if there is a way to specify that a column is identity (auto-increment)? |
| 18:28.54 | bradallen | We need to implement special logic when trying to insert a value in such a column |
| 18:29.48 | bradallen | The unit tests for Postgres are creating SERIAL column, and then later inserting values there |
| 18:30.09 | bradallen | likewise MySQL has AUTO INCREMENT columns, which the unit tests insert into |
| 18:30.48 | bradallen | I guess those databases do not require any special syntax to allow that? |
| 18:31.59 | bradallen | I am testing a backend for Microsoft SQL 2005, and it requires first issuing a special statement ( SET IDENTITY_INSERT ON tablename) |
| 18:39.45 | jkakar | bradallen: Those statements need to be run once per table, right? |
| 18:40.13 | jkakar | If that's the case, you should put them with your CREATE TABLE statements and run them with store.execute(statement). |
| 20:07.21 | bradallen | no |
| 20:07.50 | bradallen | only one table can be in IDENTITY_INSERT mode at one time for a given database |
| 20:08.10 | bradallen | SET IDENTITY_INSERT tablename ON |
| 20:08.16 | bradallen | should be run before the insert |
| 20:08.28 | bradallen | and after the insert, SET IDENTITY_INSERT tablename OFF |
| 20:10.15 | bradallen | So before each insert we will need to check if there is an attempt to insert into an identity column |
| 20:33.45 | bradallen | So in the compile_insert, I would like to be able to check whether the table has an identity column, and then check if any of the columns included in the insert statement are the identity column |
| 20:35.56 | bradallen | I guess I can pass a keyword arg to properties.Int |
| 20:36.04 | bradallen | when declaring a column |
| 20:36.28 | bradallen | idn_column = Int(identity=True) |
| 20:36.46 | bradallen | or maybe create a subclass of Int |
| 20:37.00 | bradallen | called IdentityInt |
| 21:35.26 | jkakar | bradallen: You should have a look at the way the Returning expression is handled in storm/databases/postgres.py:PostgresConnection.execute. |
| 21:36.13 | jkakar | If you create an IdentityInt you can use the same pattern to run the SET statements you need. |
| 21:42.20 | bradallen | In our custom compile_insert |
| 21:43.15 | bradallen | I will need to find out how to determine if any columns are an instance of IdentityInt |
| 21:43.54 | bradallen | and then check if that column is in the list of columns |
| 21:45.01 | bradallen | still studying the code in expr.compile_insert |
| 21:46.15 | bradallen | so I am not sure if that is the best place to put this logic |
| 21:46.22 | bradallen | but it seems like the best prospect |
| 21:55.21 | jkakar | Right. |
| 21:59.56 | bradallen | Unfortutely even after compile_mssql_insert has been adapted to handle IDENTITY_INSERT, the existing Storm backend unit tests will break |
| 22:00.11 | bradallen | because they won't be using the IdentityInt class |
| 22:02.16 | bradallen | I can alter the tests for now... |
| 22:03.25 | bradallen | but we are hoping this code eventually finds its way to Storm trunk |
| 22:05.01 | bradallen | I am not sure if the Storm team will want to support notation for identity columns in the unit tests |
| 22:05.58 | bradallen | Also, it seems to me that a keyword arg is more appropriate for specifying identity, rather than a special class |
| 22:09.20 | bradallen | ...because all the other properties are data types |
| 22:10.08 | bradallen | and it is possible to imagine the identity property attached to other data types, not only Int. For example float or decimal columns can auto-imcrement |
| 22:13.01 | bradallen | Also, I am undercertain whether 'identity' is the best name for such a keyword |
| 22:13.11 | bradallen | Postgres uses the word SERIAL |
| 22:13.17 | bradallen | MySQL calls it AUTO INCREMENT |
| 22:13.23 | jkakar | Yeah |
| 22:13.27 | bradallen | MS SQL calls it IDENTITY |
| 22:13.50 | bradallen | I wonder what SQL Alchemy calls it |
| 22:13.57 | bradallen | assuming they are handling it |
| 22:14.05 | bradallen | guess I can look that up. |
| 22:21.31 | bradallen | SQL Alchemy is using schema.Sequence objects |
| 22:21.46 | bradallen | http://www.sqlalchemy.org/docs/04/sqlalchemy_databases_mssql.html |
| 22:22.54 | bradallen | Since they have schema management, the Sequence constructor accepts seed values as parameters |
| 22:23.31 | bradallen | Storm would not need that since it is not in the business of creating tables |
| 22:24.02 | bradallen | I think just a keyword to flag that certain columns are auto increment |
| 22:24.27 | bradallen | I don't think the term Sequence used by SA is a good choice either |
| 22:24.38 | bradallen | probably the most clear is auto_increment |
| 22:40.30 | bradallen | Looks like the unit tests in store.base contain both raw inserts and store.add calls |
| 22:41.37 | bradallen | I can override the raw methods in my test subclass to that they add IDENTITY_INSERT |
| 22:43.27 | bradallen | but the store.add calls depend on a lot of classes in store.base .... I might as well copy the whole module and modify it |
| 22:44.37 | bradallen | looks like it will get ugly |
| 22:45.24 | bradallen | (I meant to say tests.store.base, not store.base) |
| 22:52.20 | *** join/#storm bac (n=bac@cpe-065-190-187-178.nc.res.rr.com) |