Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-11-30

| Channels | #askriba index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
08:53 karjala_ joined #askriba
09:21 ashimema frew: the sqltargs variable is set to `$VAR1 = {
09:21 ashimema 'ignore_index_names' => 1,
09:21 ashimema 'ignore_constraint_names' => 1,
09:21 ashimema 'add_drop_table' => 1
09:21 ashimema };
09:21 ashimema sorry.. should have stuck that in a proper pastebin somewhere.. i'm not fully awake yet today
09:25 ashimema I don't think setting add_drop_table is a bad idea as such.. perhaps it's SQL::Translator::Producer::PostreSQL that has the bug.. I'm not sure where I stand on arguing the case for having the DROP TABLE statement that Producer produces always include an IF EXISTS
09:25 ashimema what do you think about that ribasushi ?
10:28 ribasushi ashimema: I think I misunderstood your original issue
10:28 ribasushi is the problem that:
10:28 ribasushi 1) you do get a newly added drop table which eats some data
10:28 ribasushi OR
10:29 ribasushi 2) you never had that table in the 1st place, and now DBICDH adds the DROP and there are (benign yet noisy) warnings all over the place
10:35 ashimema it's the second one
10:35 ashimema these are for new tables..
10:36 ashimema now that the sqltargs are getting passed properly it adds the 'ass_drop_table' key which adds a drop table statement before any create table statements (which it didn't do before)..
10:36 ashimema the question is whether it's a good idea to have those DROP TABLE statements at all and if it is a good idea whether the IF EXISTS form should be used..
10:37 ashimema at the moment Postgres rejects the update because the table doesn't exist and the whole update rolls back.
10:37 ribasushi ashimema: https://metacpan.org/source/ILMARI/SQL-Translator-0.11021/lib/SQL/Translator/Producer/PostgreSQL.pm#L352-357
10:37 ribasushi the problem is that "IF EXISTS" is a relatively recent addition ( I say relatively - pg 7 is still in use )
10:38 ribasushi so the real issue is that for *some* reason SQLT is not passed the backend version
10:38 ribasushi this is supposed to happen here:
10:39 ribasushi https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/lib/DBIx/Class/Storage/DBI/Pg.pm#L235-242
10:39 ribasushi ashimema: if you do not get the "if exists" - then somewhere along the way things get dropped, you'll have to find where :/
10:40 ribasushi it's quite possible that DBICDH does not use DBIC's overload at all, which means it'd have to replicate what we do in what I linked and other spots like:
10:40 ribasushi https://github.com/dbsrgits/dbix-class/search?q=%24sqltargs->%7Bproducer_args%7D
10:45 ribasushi frew: all of this aside, having "add_drop_table" on by default seems dangerous... though I can't put my finger on it
10:51 ribasushi ashimema: I have to detach, hopefully the above can help narrow things down a bit
10:51 ribasushi &
11:05 ashimema thanks :)
16:37 frew ribasushi: I guess; I always expected people to want it for when they remove tables
16:38 frew also lol @ ass_drop_table
16:39 frew oh I see, it's not dropping when tables are removed, but dropping in case they already existed
16:39 frew I completely agree
16:39 frew this goes against the DBICDH model, where you are expected to be running from a known state
16:40 frew ribasushi, ashimema: I am going to sleep on this, but I am pretty confident that we should simply remove that value.
16:40 frew I don't htink it's dangerous though, unless someone has transactions off
19:56 karjala_ joined #askriba

| Channels | #askriba index | Today | | Search | Google Search | Plain-Text | summary