Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-09-10

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

All times shown according to UTC.

Time Nick Message
01:55 ilbot2 joined #askriba
01:55 Topic for #askriba is now Where random Perl5-related questions get definitive answers. Conversation log: https://is.gd/askriba_irclog (searchable). Currently no preset business hours due to low demand: just highlight my name and I'll answer ASAP \o/
04:04 dboehmer joined #askriba
05:26 karjala_ joined #askriba
06:35 karjala_ joined #askriba
07:50 ribasushi karjala_: this sounds like a dangerously wrong way to go about it, can you explain what is it you want to do?
07:50 karjala_ ok
07:51 karjala_ As you might know, Mojolicious has the ability to serve muliple clients at the same time from the same process
07:51 karjala_ So each user could have their own transaction open
07:51 karjala_ database transaction, I mean
07:51 karjala_ at the same time
07:51 karjala_ that requires more than one $schema objects existing at the same time
07:52 ribasushi this is not entirely right
07:52 ribasushi $schema doesn't know about DBI at all
07:52 ribasushi $schema->storage does
07:53 karjala_ But each $schema[1], $schema[2] variable contains a different ->storage, doesn't it?
07:53 ribasushi however "use a number of $storage objects from a pool" very quickly becomes a problem *because* of transactions
07:53 ribasushi karjala_: nothing prevents you from sharing one storage between multiple schemas
07:54 ribasushi karjala_: the problem however is that it is extraordinarily hard to prevent logic leakage this way
07:54 ribasushi if you:
07:54 ribasushi 1) have a reliable way to tell "this connection is done, it can go back to the pool"
07:54 ribasushi 2) have a constraint on how many connections you can open
07:54 ribasushi then simply feed a coderef to $schema->connect
07:55 ribasushi teach that coderef how to get a $dbh from a pool
07:55 ribasushi and... that's it
07:56 ribasushi errrr you'll also need to $schema->storage->disconnect when you are done in this particular case ( I think, you'll have to look up the logic )
07:56 karjala_ Wouldn't such a setup disallow me from forking the process if I want to? I mean handing $schema->connect a $dbh object is not fork-safe (I think) is it?
07:57 karjala_ or even handing it a coderef that returns a $dbh
07:57 ribasushi karjala_: you asked this question a week ago both here and in #dbic and it was definitively answered: DBIC takes care of this for you, by reconnecting in each fork on its own
07:57 ribasushi *however*
07:57 ribasushi mojo's async processing combined with heavy forking doesn't make much sense
07:58 karjala_ I was told back then that I should use the form ->connect($dsn, $username, $password) especially in order to make it fork safe, or something similar
07:58 karjala_ not heavy forking, just once in a while
07:58 ribasushi that didn't come from me
07:58 karjala_ o, ok
07:58 ribasushi any form of connect is fork/thread safe, because the moment there is a child - DBIC force-disconnects it
07:59 karjala_ so it IS fork-safe to give it a $dbh, then? ok
07:59 ribasushi and then tries to connect anew ( whether that succeeds or not - is another story )
07:59 ribasushi read my last 2 sentences
07:59 karjala_ yes
08:00 karjala_ So just calling My::Schema->connect($dsn, $u, $p) three times won't give me three $schema objects with three different database connections? (I'm asking, because I'm trying to find the simplest possible way to code this)
08:00 ribasushi it will give you 3 distinct schemas
08:01 ribasushi there *isn't* a "simple" way to do what you are trying to do at all - all of them have a ton of caveats
08:02 ribasushi but at this point ( you have *just* started to learn this ) it is very difficult to explain *why* this is so
08:02 ribasushi so try a couple mock-ups and show some code that we could discuss
08:02 karjala_ aha
08:02 karjala_ ok thanks!
08:02 ribasushi this is not a subject that can be talked about in the abstract, it is too complex ( trust me on this )
08:03 karjala_ ok I trust you. Maybe I should stick with 1 concurrent client per mojolicious process
08:03 karjala_ I'll do an implementation for fun, when I get the time, and I'll show it here
08:04 karjala_ thanks
08:04 karjala_ My sites aren't high-traffic anyway
08:04 karjala_ so no need for more clients per process
16:59 karjala_ joined #askriba
20:51 karjala_ joined #askriba

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