Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-05-15

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

All times shown according to UTC.

Time Nick Message
04:04 dboehmer_ joined #askriba
10:34 Ovidius joined #askriba
10:35 Ovidius We have a large team of developers working on a single application and we use a moderately complex DBIx::Class::Schema::Loader setup to generate our classes from PostgreSQL. However, on my laptop (and not my desktop, or any other developer’s computer), the schema loader omits the schema name “veure” from sequences and data types. We can’t find any differences in module versions or in database setup. Any idea why this
10:35 Ovidius would happen?
10:35 Ovidius The paste server seems to be down, so our schema generator is here: https://gist.github.com/Ovid/ab9daa0faa9bcd825271155bb435c92b
10:36 Ovidius @ribasushi ^^ :)
10:39 ribasushi Ovidius: hi!
10:39 * ribasushi reads...
10:41 ribasushi Ovidius: so like... it behaves as if https://gist.github.com/Ovid/ab9daa0faa9bcd825271155bb435c92b#file-recreate-schema-pl-L74 is omitted?
10:41 ribasushi making sure I understand what the problem is...
10:42 Ovidius Hold on. The affected laptop is rebooting after an OS X update right now. I can paste a short diff example in a minute or two.
10:42 ribasushi sure thing
10:44 Ovidius Bah. Laptop informs me it will be about 15 minutes until the install is complete :/
10:45 ribasushi Ovidius: no sweat
10:48 ribasushi Ovidius: once you are done with everything - I'd strongly suggest throwing a -MModule::Versions::Report and confirming that indeed "everything is the same"
10:48 ribasushi I vaguely recall DBD::Pg returning different table-info depending on version e.g.
10:48 ribasushi things like that
10:48 Ovidius ribasushi++
11:08 ribasushi if everything still the same - my next stop would be to look at $dbh->column_info( undef, $schema_name, $some_table_name, '%' )
11:08 ribasushi and see if that differs ( it has to, there seems no other S::L code that mangles this
11:09 ribasushi and if they do differ - then... I am out of ideas as this is raw data coming from DBD::Pg at this point :/
11:09 ribasushi Ovidius: ^^
11:09 Ovidius Will check
11:11 ribasushi errrr should have mentioned the above returns a $sth, so you'd need to ->fetchall_arrayref on it
11:12 ribasushi and then Devel::Dwarn it or something, just to see what it looks like
11:12 ribasushi ( docs of the fields etc are in https://metacpan.org/pod/DBD::Pg#column_info )
11:24 Ovidius ribasushi: the only difference in column_info on the “character” table is “ORDINAL_POSITION: The column sequence number (starting with 1).”
11:25 Ovidius That is different on two columns, but it also seems like it’s not a big deal.
11:25 ribasushi Ovidius: which S::L version are you using?
11:26 ribasushi 0.07046 ?
11:26 Ovidius Yes, on all boxes.
11:27 Ovidius And Module::Versions::Report didn’t reveal anything looking suspicious :(
11:27 ribasushi that's good, means we are getting closer ;)
11:31 ribasushi Ovidius: so are you saying, that on both boxes, when you run the query against a mismatched table, you get this value being *the same* https://metacpan.org/source/ILMARI/DBIx-Class-Schema-Loader-0.07046/lib/DBIx/Class/Schema/Loader/DBI.pm#L527
11:31 ribasushi yet S::L creates different dumps? this... doesn't seem plausible
11:31 ribasushi this is the only spot in the pg-load-cycle that processes sequences: https://metacpan.org/source/ILMARI/DBIx-Class-Schema-Loader-0.07046/lib/DBIx/Class/Schema/Loader/DBI/Pg.pm#L312-318
11:33 ribasushi after this "set()" the sequence seems to not be touched again
11:34 ribasushi Ovidius: if all else fails - "insert some print statements" is the next stop
11:43 Ovidius Will check that out, ribasushi.
11:44 ribasushi Ovidius: ilmari's hunch is correct here, so points go to him
11:45 ribasushi though I am still confused how did you manage to run the queries and not notice the difference
11:46 Ovidius Me too, but the column_info generated for the character table (one of the tables affected) shows only the ordinal_position difference whenI do a diff.
11:46 ribasushi somehow you are not running as the user you think you are running under
11:49 Ovidius ribasushi: from the command line, I connect as ovid instead of veure_user. That hid the search path info :)
11:50 ribasushi hehe, "don't change your test env" is a bit debugging 101 :D
11:50 ribasushi but glad you figured it out!
11:55 Ovidius Not sure when that happened. Must have been many months ago :)

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