Perl 6 - the future is here, just unevenly distributed

IRC log for #askriba, 2016-10-19

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

All times shown according to UTC.

Time Nick Message
04:02 frew- joined #askriba
10:19 Simon^ joined #askriba
11:27 ribasushi Simon^: right so on your earlier question in #dbic - the first part you need to answer is "will this interoperate with other 'inserters/updaters'"
11:28 ribasushi Simon^: this will dictate whether you use a default value RDBMS-side (how to do it via deploy() is a secondary question) or whether you will do it app-side via something like DBIC::Timestamp
11:29 ribasushi Simon^: in other words: is your DBIC app the only thing writing to this database, or not
11:35 Simon^ the DBIC app *should* be the only thing writing to the database.
11:36 Simon^ The only exception might be the odd bit of manual tweaking where something goes horribly wrong, but in those cases I wouldn't be too concerned with updating a modification date.
11:36 ribasushi Simon^: right, then doing the Timestamp route is better because you don't have to worry about appserver/rdbmsserver clock sync
11:37 ribasushi Simon^: now, it was said that an object is marked dirty any time you call an accessor - this is incorrect: laziness is being preserved as much as possible, specifically on these lines:
11:37 ribasushi https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/lib/DBIx/Class/Row.pm#L945-952
11:37 Simon^ I did think that sounded a bit wrong
11:38 ribasushi the second part being https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082840/lib/DBIx/Class/Row.pm#L998-1023
11:38 ribasushi Simon^: on the last part - I am not sure I understood the exact case when your update does *not* call ::Timestamp
11:38 ribasushi Simon^: can you elaborate on that?
11:39 ribasushi the thing you mentioned "I do in my test" is entirely legit
11:41 Simon^ Sorry, not sure I follow the bit about not calling ::Timestamp.
11:41 ribasushi Simon^: "...  sometimes it uses the current time, sometimes it uses what I passed to it."
11:41 ribasushi Simon^: it doesn't sound right, and the explanation didn't seem right either
11:42 ribasushi I was wondering what is the actual chain of calls that leads to this
11:42 ribasushi i.e. it should *always* use what was passed in
11:42 Simon^ Exactly what I said for the test.. the ->find() followed by updating to the same value each time.
11:43 ribasushi huh... let me try that locally, this certainly isn't... right
11:43 Simon^ if I set the date_modified to a value, the first time it works, then the second time it uses the current time, and then it alternates after that.
11:43 Simon^ that's only when the value passed is the same each time.
11:45 Simon^ https://gist.github.com/TUKSimon/30bfd75925b94810bdb2c76f22cfc08d
11:46 ribasushi Simon^: right, let me check that codepath... 5 mins
11:46 Simon^ It's part of a catalyst app, hends the RNPS->model()
11:46 Simon^ hence
11:48 ribasushi Simon^: are you using always_update?
11:48 Simon^ I don't think so, where would that be?
11:48 ribasushi then no, nevermind, let me construct a local test, what you are describing sounds really wrong/bad
11:49 Simon^ grep for always_update returns nothing so it's unlikely.
11:49 ribasushi aye
11:51 ribasushi Simon^: can you show what does your RnpsLog result looks like
11:51 ribasushi ?
11:52 Simon^ the data dumper part?
11:52 ribasushi no
11:52 ribasushi the class definition
11:52 ribasushi load_components and all that
11:55 Simon^ https://gist.github.com/TUKSimon/9a4e490c21d45a35a5cb16005a21b87c
11:56 Simon^ Just noticed I have load_components twice - probably because it was originally auto-generated and then I hacked it around a load.
12:00 ribasushi Simon^: this shouldn't matter, I seem to be able to reproduce it locally intermittently, looks like a proper bug with DynamicDefault
12:01 ribasushi Simon^: still looking...
12:09 ribasushi hm... really bizarre, still looking ;)
12:10 Simon^ no worries, take your time :)
12:26 ribasushi Simon^: sadly it's a bug in one of the lower level libs :/
12:26 ribasushi Simon^: I filed a bug on your behalf, but haven't looked into a fix https://rt.cpan.org/Ticket/Display.html?id=118434#txn-1677482
12:27 ribasushi Simon^: it's likely not too hard to fix, so I encourage you to take a crack at it if time permits
12:29 ribasushi ( note: I disagree with your earlier assesment in #dbic that the failure in question is an unlikely scenario - quite the contrary ;)
12:34 Simon^ well, I can't imagine that I'm likely to force the modification date/time very often, most of the time it'll be 'now' and the column wouldn't be specified.
12:34 ribasushi your call, I am just a messenger ;)
12:43 SysPete joined #askriba
17:39 dboehmer joined #askriba
17:39 wesm left #askriba

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