Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2017-09-09

| 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:17 karjala_ joined #askriba
05:25 karjala_ I wonder if, in order to setup & use business objects in the front, similar to what we said a few days back, and let them use DBIC in the back, I should create a Result method $result->upgrade which will generate a Moose class (the business object, we mentioned) holding the $result as one of its parameters
05:25 karjala_ And similarly, on resultsets, do $rs->upgrade = map { $_->upgrade } $rs->all;
05:26 karjala_ I mean, I think that I *should* have a way to go from DBIC object to Business object
05:27 karjala_ and wonder whether I'm on the right track
05:50 ribasushi karjala_: this doesn't sound quite right tbh
05:50 karjala_ oh
05:50 ribasushi if you are going to tie the objects 1:1 ( a business domain object for every result object ) , then you are not gaining much, might as well use the Results themselve
05:51 karjala_ a
05:51 ribasushi what I suggested was "grow your business layer independently of your schema"
05:51 karjala_ a
05:51 ribasushi all the formatting etc stuff should go into this layer
05:51 ribasushi leaving "raw data munging" to the dbic-based layer
05:51 ribasushi if *all* you are interested is extra formatting
05:52 ribasushi then having some extra methods on Result classes ( via a base-class perhaps ) - would be sufficient
05:52 ribasushi ( thought *do not* try to shoehorn formatting/filtering/etc into the usual DBIC retrieval cycle - this way lies pain )
05:53 ribasushi additionally map { $_->upgrade } is a bit wasteful
05:53 karjala_ there's an inflator method i think - should i not use that?
05:53 karjala_ where you can choose your inflator and deflator
05:53 karjala_ i dont remember the specifics
05:54 karjala_ ok
05:54 ribasushi you can, but it has limitations
05:54 ribasushi the most popular one is DateTime
05:54 karjala_ for example, I often need a TEXT field to hold JSON-encoded objects
05:54 ribasushi but while you can use it within the "Result-object plane"
05:54 karjala_ that inflate into hashrefs
05:54 ribasushi you can not use the same logic within search()
05:55 karjala_ a
05:55 ribasushi karjala_: you could write something for that, yes
05:56 ribasushi ( because you are inlikely to ever need the values on the ResultSet side )
05:56 ribasushi anyway - on your map ... ->all question: there is also the facility of result_class ( search->( {...}, { result_class => $custom_class } )
05:57 karjala_ o
05:57 ribasushi which when supplied will call $result_class->inflate_result( ... ) every time you call ->all / -> next
05:57 ribasushi but again - doing this *everywhere* will give you more problems than it will solve
05:59 karjala_ so I should create my business domain objects and classes independently of the actual DB schema?
05:59 karjala_ or at least not 1:1 necessarilly?
05:59 ribasushi don't be discouraged by my answers being vague - architecture is a vague topic with no "right answers"
05:59 karjala_ a i see
05:59 ribasushi the answer always 95% depends on what are you trying to build, so when you ask me for generic advice - I can't give you universal answers
06:00 karjala_ I wonder if there's an example of such an application on the net
06:00 karjala_ or whether I need to get employed somewhere to see it in practice
06:00 karjala_ ok
06:00 karjala_ Right
06:01 karjala_ So the templates (eg in a webpage) should use DBIC result- objects directly, right?
06:01 karjala_ not wrappers
06:02 ribasushi it's a hard question
06:02 karjala_ I'm thinking of this scenario:
06:02 ribasushi it is simpler to do that - hand objects to the template
06:02 ribasushi but then you hand a *live* reader/writer to the template
06:03 karjala_ I don't mind, I trust the developers
06:03 karjala_ shouldn't i?
06:03 ribasushi so there could be a temptation to go ahead and call extra DB-effecting shit *within* the template
06:03 karjala_ a
06:03 ribasushi and where there's temptation - there's ( later ) actual use
06:03 ribasushi if you are confident "this will be used by more than myself"
06:04 ribasushi I'd probably either hand in the result as a hash
06:04 karjala_ a yes!
06:04 karjala_ with a result_class => HashRefInflator?
06:04 ribasushi for instance
06:05 karjala_ interesting
06:05 ribasushi *however* - if you use that - then you have to give up inflate_column
06:05 karjala_ o
06:05 karjala_ I could make my own hashrefinflator which also inflates columns
06:05 ribasushi because HRO can never call them
06:05 ribasushi yes and no
06:06 ribasushi all DBIC::InflateColumn routines expect a result object - there is no object to hand them to do the inflation - what do you do?
06:06 ribasushi ( this is an old, now unfixable misdesign )
06:06 ribasushi *another* option is to "disarm" your result objects
06:07 karjala_ how would i do that?
06:07 ribasushi $result->result_source( undef ) will disconnect it from the rest of the schema, so while their accessors will work, there won't be ability to call $result->search_related(...)
06:07 karjala_ nice
06:07 ribasushi and $result->delete will fail too
06:08 ribasushi ( because it won't know where the $dbh for this is )
06:10 ribasushi karjala_: I have to go, hopefully one of these ideas will deem useful
06:10 karjala_ My scenario is this: I have a Devices table, and I can telnet to devices. So I'd like each $device to have a ->telnet method, which will return a Net::Telnet object - the same telnet object each time I call ->telnet
06:10 karjala_ ok thanks, indeed they help!
06:11 ribasushi karjala_: tell me a bit more
06:11 ribasushi karjala_: perhaps what you are trying to do is already written
06:12 karjala_ Basically I just want something like Moose's 'has', that holds a constant value for the lifetime of my result object
06:12 karjala_ it's quite simple really
06:13 ribasushi no
06:13 ribasushi you said something about devices and telnet
06:13 karjala_ Yes
06:13 karjala_ Net::Telnet->new will create a telnet object
06:13 karjala_ and I can have it connect, as well
06:13 karjala_ I've done that, and hold a $telnet variable with this object
06:13 ribasushi no, I mean - what are you doing
06:13 ribasushi not in code
06:14 karjala_ A
06:14 ribasushi but in practice
06:14 ribasushi what is the code solving
06:14 karjala_ I'll write in private, because it's business
06:14 ribasushi sure
06:18 karjala_ so I was hoping for a way to make my code "prettier"
06:18 karjala_ not more functional
06:18 karjala_ ie tidy up the pieces, make it more modular
06:18 karjala_ etc
06:18 ribasushi alright, so essentially you are writing something like a "control center" for a bunch of devices
06:19 karjala_ yes
06:19 ribasushi at first it seems like you are doing discovery, which is why I asked you
06:19 ribasushi as there is a mature perl project https://metacpan.org/release/App-Netdisco which does this
06:19 karjala_ what's discovery?
06:19 karjala_ aha ok
06:19 ribasushi "I am a new sysadmin - tell me about this network, whatever you can find"
06:20 karjala_ interesting
06:20 karjala_ like netmap
06:20 karjala_ ?
06:20 karjala_ nmap
06:20 ribasushi yes but way more sophisticated
06:20 ribasushi scroll down the list of modules this dist has, the names will give you an idea
06:20 ribasushi now - I have *not* looked into its code so I do not know if it uses DBIC "well" or not
06:20 ribasushi but it is a complete app you could likely get some ideas from
06:21 karjala_ ok
06:22 karjala_ I bookmarked it in my perlmodules.net
06:22 ribasushi but going back to your question "I just want a few has() for the lifetime of the result object" - then this is sufficient: https://irclog.perlgeek.de/askriba/2017-09-06#i_15124833
06:23 ribasushi it's when you have a 100 accessors you added and 10 actual columns, and you are trying to figure out how to cram it into json or somesuch - this is where it gets... ugly
06:23 ribasushi so try to predict whether complexity will explode in this direction and plan accordingly
06:24 ribasushi and now I really have to go, later &
06:24 karjala_ excellent bye
09:02 karjala_ I realized it should be easy to create a function/method that returns $schema objects from a pool
09:03 karjala_ and returns the $schema (with its database connection) to the pool, once the variable holding it goes out of scope
09:04 karjala_ in order to reuse database connections, on a system like Mojolicious which serves many clients at the same time (each must have their own $schema object)
14:34 karjala_ joined #askriba
19:01 karjala_ joined #askriba

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