Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2018-01-28

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

All times shown according to UTC.

Time Nick Message
05:04 dboehmer joined #askriba
11:14 ribasushi mohawk: regarding DBIx::Class::Schema::Loader::SQLT => what are you actually trying to do?
11:16 karjala_ joined #askriba
16:52 SysPete left #askriba
17:07 mohawk ribasushi, make DCSL be able to read its structure not just from a DBI handle, but also an SQLT schema
17:15 ribasushi mohawk: to what end? it seems to go exactly in reverse to how the stack operates, can you explain what are you trying to do from a birds-eye view?
17:19 ribasushi mohawk: trying to save you time going the (almost certainly) wrong path, but can't do so without knowing more
17:33 mohawk ribasushi, firstly to me it seems a bit incomprehensible to have two separate pieces of code that can talk to a DB and extract its shape, for similar but slightly disconnected purposes
17:35 ribasushi SQLT can't talk to a live DB - it has *some* code for it, but it is in beyond-disrepair
17:35 ribasushi DBICSL can *only* talk to a live DB
17:35 ribasushi hence when you say "I want DBICSL to load from SQLT" - it sounds precisely backwards
17:36 mohawk i'm trying to remember the specific use-case
17:37 mohawk i don't see any downside to having DCSL be able to understand an SQLT
17:37 mohawk and SQLTs can come from things that aren't a DB
17:38 ribasushi there is also no upside, which is why I figured I will check whether you got yourself into a logical dead-end
17:38 ribasushi but if you believe I am wrong, and it is just hard to explain why - more power to you ;)
17:38 mohawk one thing i do want to be able to do, is generate a GraphQL schema from various things (which i can do now) or indeed from just a written-out schema, and generate a DB from that
17:39 mohawk i did know the answer several months ago, now i'm trying to recall it. certainly your question is an excellent one :-)
17:40 ribasushi I got to run, will read later in case you recall where things were ;)
17:40 mohawk grin, enjoy
17:41 ribasushi mohawk: one last thing ( not exactly knowing what "generating a graphql schema" entails )
17:42 ribasushi the general answer for "I want to generate X out of SQL dumps and out of live databases and out of existing-as-code DBIC schemas"
17:42 mohawk i made an SQLT producer to GQL, which uses the SQLT->DBIC, then introspects the DBIC schema
17:42 mohawk but it was a bit unsatisfactory since i wanted to get DCSL-style camelcasing and so on but the DBIC thing didn't do that
17:42 ribasushi considering which pieces are maintained and which ones are in disrepair
17:42 ribasushi the workflow would be:
17:43 ribasushi ( in case of live DB ) DBICSL => DBIC => SQLT::Parser::DBIC => SQLT::Producer::GraphQL
17:43 ribasushi ( in case of existing DDL-in-file ) SQLT::Parser::whateverddlreader => SQLT::Producer::GraphQL
17:44 ribasushi ( in case of DBIC classes ) DBIC => SQLT::Parser::DBIC => SQLT::Producer::GraphQL
17:44 ribasushi ^^ these are the paths that are the most "polished" ( they still suck, but they are better than other alternatives )
17:44 mohawk ok
17:44 mohawk i'll type in my thoughts based on the above, enjoy your run ;-)
17:51 mohawk ribasushi, the relevant part of a GQL schema for these purposes: you have object types, which have fields, each of which has a type that can be either scalar or another object type
17:51 mohawk that last one is effectively an FK relationship
17:52 mohawk it maps fairly nicely to relational, which is not a coincidence
17:53 mohawk to make a meaningful schema from "dumb data", you need to figure out your CRUD, which i've done and isn't part of this issue
17:53 mohawk here's the 10-line thing i'm doing in my graphql "producer": https://metacpan.org/source/ETJ/SQL-Translator-Producer-GraphQL-0.04/lib/SQL/Translator/Producer/GraphQL.pm#L12-22
17:54 mohawk here's the "convert" it uses, which was based on a probably-not-ideal module, but works: https://metacpan.org/source/GraphQL::Plugin::Convert::DBIC
17:55 mohawk you'll see the 10-line thing does this to get a DBIC schema: eval SQL::Translator::Producer::DBIx::Class::File::produce($dbic_translator);
17:56 mohawk if you were to say to me now that it should instead be introspecting the SQLT schema directly, i'd agree
17:57 mohawk but then i would ask why i would want to also maybe need to introspect a DBIC schema
21:46 ribasushi mohawk: right it boils down again to "these are the codepaths that people actually use and they are not horrible"
21:46 ribasushi for instance SQL::Translator::Producer::DBIx::Class::File is virtually unmaintained, not for other reason but you are its first user I've heard of since ~2010
21:47 ribasushi note - I am not necessarily trying to stop you from improving an alternative path
21:47 ribasushi but rather seeing what you are trying to build - adding SQLT => SL bridging seems orthogonal at best
23:18 mohawk sure
23:18 mohawk thanks for the thoughts, i'll ponder accordingly :-)
23:42 mohawk yes, the DBICF one seemed a bit... uncomplicated. however it works so i'm not complaining :-)

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