Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2018-01-05

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

All times shown according to UTC.

Time Nick Message
05:04 dboehmer_ joined #askriba
08:32 ashimema hmm.. confused by a multi-create
08:33 ashimema just going to come up with a paste to demonstrate
08:44 ribasushi ashimema: I got to leave for 40 mins, will read when I am back
08:46 ashimema okies
08:46 ashimema thanks
09:06 ashimema https://gist.github.com/mrenvoize/debbcfacc5c4e3dc75e813410b3f868b#file-result-listchange-pm-L87
09:06 ashimema The comment on the gist outlines the error I'm getting.. the gist itself includes the full result classes for the two classes involved and a snippet from the controller that's calling them
09:07 ashimema happy to add more context but didn't want to throw too much in at once as it's already allot there.
09:09 ashimema I basically have an optional belongs_to in one class (with a check constraint to ensure at least one of the multiple belongs_to is satisfied (MTI)) and a has_one in the other class and I want cascades to work both ways on delete.. that's why the classes are the way they are though I'm open to advice.
09:25 ribasushi if the belongs_to is optional
09:26 ribasushi then has_one is wrong - has_one says "my *child* always exists" ( which in itself is circular, which is why has_one is a design mistake )
09:26 ribasushi but that aside - you are essentially confusing the resolver
09:26 ribasushi switch to might_have and everything will likely just work
09:26 ribasushi ( reading in more detail now... )
09:26 ribasushi ashimema: ^^
09:27 ashimema back.. sorry was sorting out the kids ;)
09:28 ribasushi also... request is a 1:1
09:28 ribasushi why are you feeding it a [ ] ?
09:28 ribasushi https://gist.github.com/mrenvoize/debbcfacc5c4e3dc75e813410b3f868b#file-controller-priority-pm-L4 <--- here
09:28 ashimema https://metacpan.org/pod/distribution/DBIx-Class/lib/DBIx/Class/ResultSet.pm#create
09:28 ashimema 'Example of creating a new row and also creating rows in a related has_many or has_one resultset. Note Arrayref.'
09:28 ashimema that's why ;)
09:29 ashimema I actually fed it just a hashref to start
09:29 ashimema and switched to arrayref when I saw it in the docs
09:29 ashimema I'm still slightly confused
09:29 ribasushi sigh.... docs are suboptimal ( to say the least )
09:29 ashimema the has_one should always have a corresponding row
09:30 ashimema it's the belongs_to in the corresponding class that is optional
09:30 ribasushi then your rels are the wrong way around entirely
09:30 * ashimema wonders if you meant switch the belongs_to to a might_have instead
09:30 ribasushi no - has_one has to go , to what you switch it depends on what the exact relationship is
09:30 ribasushi again - has_one is a mistake within DBIC itself, it has no practical use
09:31 ribasushi ( there is a plan how to gracefully deprecate all of that, but community happened :/ )
09:31 ribasushi ashimema: let me dig you out a link, sec
09:31 ashimema thanks
09:32 ashimema I did see the MTI module but haven't had a chance to dig into it in depth yet..
09:32 ribasushi https://rt.cpan.org/Public/Bug/Display.html?id=83712#txn-1187773
09:32 ribasushi ashimema: ^^ read just this comment, it will give you the entire gist on relationships, and what I said above will start making sense
09:33 * ashimema has phones ringing at him from every direction all of a sudden
09:33 ribasushi ashimema: the basis of your problem is that ( I think ) you need to swap has_one to belongs_to, and swap the other belongs_to with might_have
09:34 ribasushi but first read the link as a certain level of comfort with the concepts is required before fixing this
09:34 ashimema and switch my relation fields from one table to the other I presume by that
09:35 * ashimema reads the comment for a moment
09:35 ribasushi no! no switching of fields
09:35 ribasushi <ashimema> the has_one should always have a corresponding row <--- you described belongs_to
09:35 ashimema oh.. I think I follow now
09:35 ribasushi <ashimema> it's the belongs_to in the corresponding class that is optional <---- you described might_have
09:36 ashimema it's another misleading statement in the docs me thinks then.
09:36 ribasushi quite likely :/
09:36 ashimema I would do some doc updates but these days I'm totally confused by where I'd submit a pull request and be most useful to people
09:37 ashimema so this statement is incorrect: `Creates a relationship where the calling class stores the foreign class's primary key in one (or more) of the calling class columns.`
09:37 ribasushi what is this attached to?
09:38 ashimema https://metacpan.org/pod/DBIx::Class::Relationship#belongs_to
09:38 ribasushi no, it is correct
09:38 ribasushi let's step back
09:38 ashimema but in my case it's the foreign class that stores the calling classes primary key for the relation
09:38 ribasushi in english, what are you modelling?
09:40 ashimema i'm modelling a series of different requests.. every request shares a common basic set of fields and the individual request types add various additional fields.
09:40 ribasushi so listchange is a subtype of request
09:40 ashimema yup
09:41 ribasushi and you elected to have listchange being the core "item" with request "pointing" at it
09:42 ribasushi when you add extra subtypes, do you plan to keep adding FK columns to the request table?
09:42 ashimema at this point I am
09:42 ashimema I had it the other way around but I couldn't get cascade deletes to work
09:42 ribasushi this won't scale well, and generally relaying on RBDMS-side cascades for this is... questionable
09:43 ribasushi so... ok several things:
09:44 ashimema Thanks for your patience with me ribasushi.
09:44 ribasushi if you keep things the way they are now - then you have:  request left-belongs_to listchange, and listchange might_have request. The reason I am saying "might_have" is because the RDBMS does not enforce anything for you, so saying has_one will tell DBIC "even when you create things - the other side is already guaranteed to be there" ( which is impossible )
09:45 ribasushi with that said - what you are doing is probably the worst way to go about it
09:45 ribasushi I would either look into MTI ( if you are on Pg ), the helper is relatively solid
09:46 ribasushi or if not - I'd go for a single request_meta table, which has a number of might_have's pointing at the various subtypes, each subtype belongs_to-ing, and a cronjob that nukes request_meta when all of its might_have's count as 0
09:46 ribasushi ashimema: ^^ this should be the full answer to where you are ;)
09:47 ashimema OK, thankyou.
09:47 ashimema I'll dig into MTI I think
09:48 ashimema though the 'relatively' there scares me ;)
09:48 ribasushi eh, you are using perl, how much worse can it get? :D
09:48 ashimema lol
09:49 ribasushi regarding docfixes: if you open a PR against the "official" branch, I will receive it too, and will eventually incorporate it into my work, but that keeps being postponed because... reasons
09:49 ashimema I thought my check constraint was reasonably good at overcoming some of the shortcomings you mention above though
09:49 ashimema shame
09:49 ribasushi the shortcoming is you having an ever-growing list of fk-columns, I would strongly advise against it
09:50 ashimema mmm, I did feel that was wrong
09:50 ribasushi we have that at work, it is not fun ( but it is a fixed set of 3, forever, so not terrible )
09:50 ashimema it came from reading this article (amongst others) https://dan.chak.org/enterprise-rails/chapter-10-multiple-table-inheritance/
09:50 ribasushi you do not seem to have this sort of limit
09:51 ashimema mm
09:52 ashimema there was once a limit.. then someone else took over the project and they're adding in all sorts of new ways ;)
09:52 ashimema thankyou for your time this morning.. I know you're a busy man
09:53 ribasushi always happy to help, this isn't an obvious topic
10:14 ashimema I now remember why I ran away from MTI before.. the docs are 'sparse' to say the least
10:15 ashimema and my reading of the code very quickly lead to me understanding it even less..
10:16 ashimema am I right in thinking if I use MTI then I should remove the relationships I've manually added currently (i.e. the might_have and belongs_to)
10:27 ribasushi ashimema: correct - each table becomes an individual thing with CRUD working on it as you'd expect
10:27 ribasushi there are no relationships to start with
10:27 ashimema I wonder what deployment handler/sql translator is going to make of this when I throw 'prepare' at it
10:28 ribasushi ¯\_(ツ)_/¯
10:28 ashimema thanks.. I'll start cleaning up those relationships
10:28 ashimema also remove the foreign key column from the add_columns
10:28 ashimema hmm
10:29 ashimema there's going to be a fair bit of fallout in my code from this I reckon
10:29 ashimema though the end result should be much neater I think
10:29 ribasushi it's all tradeoffs, if the app is way advanced dev-wise: you might do well to stick with what you have now
10:29 ribasushi hard to make a judgment not knowing your circumstances
10:32 ashimema mmm
10:56 mohawk dboehmer_, thanks!
12:27 karjala_ joined #askriba
12:58 karjala_ joined #askriba
12:59 karjala_ joined #askriba
15:18 karjala_ joined #askriba
15:34 vanstyn_ joined #askriba
15:42 SysPete_ joined #askriba
16:00 karjala_ joined #askriba
16:05 karjala_ joined #askriba

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