Wednesday, 2014-03-19

*** che-arne has joined #storyboard00:01
*** mfer has joined #storyboard00:16
*** mfer has quit IRC00:16
*** miqui has quit IRC02:05
*** che-arne has quit IRC02:17
*** jesusaurus has quit IRC05:26
*** saju_m has joined #storyboard05:58
*** jcoufal has joined #storyboard08:22
*** jcoufal has quit IRC08:54
*** hashar has joined #storyboard08:57
*** jcoufal has joined #storyboard09:24
*** jcoufal has quit IRC09:25
*** jcoufal has joined #storyboard09:26
*** jcoufal has quit IRC10:07
*** jcoufal has joined #storyboard11:13
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: Added db_api for comments  https://review.openstack.org/8123211:53
*** hashar has quit IRC12:04
*** hashar has joined #storyboard12:14
*** jcoufal has quit IRC12:19
*** hashar has quit IRC13:12
*** hashar has joined #storyboard13:14
krotscheckNikitaKonovalov: SO I found this the other day:13:16
krotscheckhttps://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/session.py13:16
krotscheckSpecifically the section on soft deletes13:17
krotscheckAFK for a bit, have to restart a few things13:17
*** krotscheck has quit IRC13:18
*** mfer has joined #storyboard13:22
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: [WIP] Comments controller  https://review.openstack.org/8150513:41
*** david-lyle has quit IRC13:48
*** che-arne has joined #storyboard14:33
*** miqui has joined #storyboard14:34
ruheNikitaKonovalov: re https://review.openstack.org/#/c/81232 - why didn't you add tests to tests/db/test_db_apy.py? migration path is also not tested.14:44
* ttx tries to celan up legacy tables again14:52
ttxclean14:52
NikitaKonovalovruhe: I found that file, tests are comming soon ..14:55
ruheNikitaKonovalov: great, thanks!14:56
ruhei just can't let myself +1 code without tests :)14:56
*** david-lyle has joined #storyboard14:58
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: Added db_api for comments  https://review.openstack.org/8123215:02
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: [WIP] Comments controller  https://review.openstack.org/8150515:03
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: Added db_api for comments  https://review.openstack.org/8123215:11
ttxthis alembic thing is confusing as hell15:24
ttxanyone knows the syntax for removing a foreign key column to a table I want to remove ?15:27
ttxmordred: ^?15:27
ttxlooks like I need to drop_constraint and then drop_column15:27
ttxbut drop_constraint wants the name of the FK constraint and the original creation did not mention any name15:28
ttxsee, that's why i didn't want us to implement migrations while we were still heavily reworking the DB15:31
ruhettx: why might want to wipe out current DB (there is too much garbage there) and use that to merge all existing DB migration scripts15:33
ruhettx: can you upload your WIP code and leave a comment where you need your changes in Alembic?15:34
ruhe*we might want15:34
ttxi'll get it to work alright, but it ain't be prett15:36
ttxy15:36
*** jcoufal has joined #storyboard15:39
*** jcoufal has quit IRC15:39
openstackgerritThierry Carrez proposed a change to openstack-infra/storyboard: Remove Branch and Milestone legacy tables  https://review.openstack.org/8156215:41
ttxruhe: that works locally... But see my comment on the brittle-ness15:43
*** krotscheck has joined #storyboard15:46
ruhettx: ack15:46
ttxboohoohoo15:50
krotscheckeh?15:51
* ttx sobs15:51
ttxkrotscheck: i'm tired of Alembic preventing me from cleaning up legacy tables15:51
krotscheckttx: Didn't ruhe fix that?15:52
krotscheckI'm guessing some other bug showed up.15:52
ttxkrotscheck: no, it's just my alembic-foo not being up to par15:52
ruhekrotscheck: that's another thing. ttx can't run migration because there is no way to delete FK which has no name15:53
ttxcan't figure how to drop that FK without getting mysql-specific15:53
krotscheckOh, interesting.15:53
ttxwhich is stupid since (1) we only want to supprot mysql IIRC and (2) we don't have a prod Db yet15:53
krotscheckYeah, that makes sense.15:53
krotscheckttx: We do have a prod db.15:53
krotscheckAt least I thought we did15:54
krotscheckDidn't mordred mention that having foreign keys in general is kind of pointless?15:54
ruheok, if everyone votes to get rid of Postgres support, it shouldn't be difficult15:54
ttxkrotscheck: well yes, but there are in the initial thing15:54
ruhebut15:54
ttxkrotscheck: so we kinda need to remove them15:54
krotscheckRighto15:55
ruhethat mean that we make our codebase MySQL specific15:55
openstackgerritNikita Konovalov proposed a change to openstack-infra/storyboard: Added db_api for comments  https://review.openstack.org/8123215:55
krotscheckHrm15:55
krotscheckSo when postgres doesn't get an FK, it auto generates a name?15:56
krotscheckSorry15:56
ttxagain, probably doable -- just a lot of skill and pain needed to clean up early mistakes15:56
krotscheckWhen it doesn't get a named FK, it auto generates one?15:56
krotscheckOr is this a sqlalchemy thing15:56
ttxkrotscheck: yep, it autogenerates one, but it's Db-dependent. And the ndop-constraint wants the name15:57
ttxdrop_constraint*15:57
ttxkrotscheck: I hardcoded the mysql autogenerated name, but that obviously fails with pgsql15:58
ttxyay.15:58
krotscheckttx: You can probably switch on the engine name - if it contains mysql do one thing, otherwise do another.15:59
krotscheckttx: And then do one single patch that drops all foreign keys.15:59
ttxif I had a clue what pgsql does use, I probably would16:00
krotscheckI hear there's documentation :)16:01
ttxkrotscheck: in all cases relying on the autogenerated name is exceptionally brittle16:04
ttxbecause it may just change16:04
ttxso I wish there was another way to fix this16:04
ttxI was unhappy with hardcoding the mysql case, i'm even more unhappy to hardcode names for all potential DBs :)16:05
krotscheckttx: Well, we could patch our previous migrations in the codebase, then manually go update the foreign key names in our prod DB.16:06
ttxkrotscheck: ah, interesting. we could even retroactively set them to the names that happen to be in our DB.16:07
krotscheck...but I don't have access. Because someone won't give it to me.16:07
ttxthat would avoid the "manually go update" step16:07
krotscheckttx: That would result in a 'clean' database so to say.16:07
krotscheckttx: Fair point.16:07
ttxyou still need to get to those names16:07
ttxkrotscheck: if we do that, i would drop all the ForeignKeys16:08
ttxif that's desirable to follow the mordred style of table creation16:08
krotscheckttx: Yes, but we can get those names simply by setting up a local db.16:09
krotscheckttx: Well, assuming the names aren't random16:09
ttxkrotscheck: assuming.16:09
ttxOK, will have a try at that16:10
ttxUnless mordred screams when he reads that backlog16:10
krotscheckmordred has broken our build more often than you have. I don't think he has any bitching rights right now.16:11
cody-somervilleI don't think we should get rid of FK. I think mordred was speaking sort of tongue-in-cheek16:19
cody-somervillealso, the inability to delete FK sounds like bug in alembic or somewhere.16:22
cody-somerville(or missing feature)16:22
cody-somervilleas alembic should be able to look the constraint name up via ANSI standard information_schema table16:24
*** hashar has quit IRC16:39
*** krotscheck has quit IRC16:55
ttxcody-somerville: yes, looks like missing feature and corner case of not specifying the FK constraint name in the first place16:59
* ttx will wait for a settlement on the desirability of FKs before writing a pathc to get rid of them16:59
*** krotscheck has joined #storyboard17:11
*** krotscheck_ has joined #storyboard17:13
*** krotscheck has quit IRC17:13
*** krotscheck_ is now known as krotscheck17:13
krotscheckHrm.18:12
krotscheckI'm looking through Oslo right now, and there's some odd feature-specific stuff in there.18:12
krotscheckLike - why does utils.model_query have an explicit property called project_id?18:13
krotscheckDo all users of the sql alchemy extensions have a concept of a project?18:13
*** saju_m has quit IRC19:21
*** saju_m has joined #storyboard19:22
*** hashar has joined #storyboard19:47
*** saju_m has quit IRC20:08
*** saju_m has joined #storyboard20:08
*** krotscheck has quit IRC20:10
ruhekrotscheck: that seems to be specific to keystone stuff21:03
*** hashar has quit IRC21:14
*** saju_m has quit IRC21:28
*** mfer has quit IRC21:30
*** che-arne has quit IRC21:33
*** david-lyle has quit IRC22:19
*** krotscheck has joined #storyboard23:30
jeblaircody-somerville: i can't speak for whether mordred was being toungue and cheek at that time, but i have heard him and enough other mysql experts say that that i personally believe he was serious.23:53
jeblairfurthermore, it is an argument that makes sense; the application needs to understand and enforce fk constraints anyway, it's wasteful to ask the db to do it as well, and tends to cause problems like this23:54
jeblairso i do think we should get rid of foreign keys in the db; the orm should still know about those relationships though23:55
jeblairkrotscheck, ttx, mordred: ^23:55
krotscheckI'm all fo rit.23:56

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!