[13:01:00 CDT(-0500)] <JasonElwood> My firefox browser keeps locking up when I access Journal Details or Steps on Linux CI. It has done it three times now. Pinwheel on the Mac kinda thing. Anybody else see this?
[13:01:51 CDT(-0500)] <dmccallum54> any user/s in particular?
[13:02:08 CDT(-0500)] <JasonElwood> sorry. this is in admin
[13:02:16 CDT(-0500)] <JasonElwood> I'm trying to test the sorting and active/inactive
[13:02:40 CDT(-0500)] <JasonElwood> I'm not experiencing this in Chrome but no pinwheel. the browser just freezes.
[13:02:49 CDT(-0500)] <JasonElwood> Sadly, hoping it/s not just me
[13:05:03 CDT(-0500)] <dmccallum54> got the beachball on details
[13:05:04 CDT(-0500)] <dmccallum54> FF
[13:06:00 CDT(-0500)] <JasonElwood> good I guess
[13:06:23 CDT(-0500)] <dmccallum54> i'm getting zillions of "Journal Step Detail 1"
[13:06:32 CDT(-0500)] <dmccallum54> maybe a data thing? maybe an infinite loop?
[13:07:28 CDT(-0500)] <JasonElwood> it's definitely new
[13:07:45 CDT(-0500)] <dmccallum54> open a new ticket?
[13:07:47 CDT(-0500)] <JasonElwood> Archna did check in some code for active staus management
[13:07:49 CDT(-0500)] <JasonElwood> I will
[13:08:34 CDT(-0500)] <JasonElwood> And tony's journal associations are there too
[13:08:41 CDT(-0500)] <JasonElwood> both checked in yesterday
[13:12:53 CDT(-0500)] <JasonElwood> Anybody volunteering for it?
[13:13:36 CDT(-0500)] * dmccallum54 ducks
[13:15:47 CDT(-0500)] <JasonElwood> Sorry Dan
[13:17:46 CDT(-0500)] <dmccallum54> dammit
[13:18:33 CDT(-0500)] <dmccallum54> i guess that's the karmic retribution for IGEN magically fixing itself
[13:19:01 CDT(-0500)] <JasonElwood> It's probably more in tony's court, but I know he's focused on CL.
[13:19:09 CDT(-0500)] <dmccallum54> that's fine
[13:28:55 CDT(-0500)] <JasonElwood> unless you guys need something, I'm going to bail
[13:29:03 CDT(-0500)] <dmccallum54> later
[13:29:14 CDT(-0500)] <JasonElwood> DM- if you can let me know when IGEN is stable, I'll complete the configuration
[13:29:23 CDT(-0500)] <dmccallum54> will do
[13:29:28 CDT(-0500)] <JasonElwood> thanks.
[13:29:30 CDT(-0500)] <dmccallum54> vicky's still looking at it
[13:29:36 CDT(-0500)] <dmccallum54> somehow magically fixed itself overnight
[13:29:40 CDT(-0500)] <dmccallum54> which is no good, really
[13:29:55 CDT(-0500)] <JasonElwood> agreed
[13:57:15 CDT(-0500)] <Patty_> does anyone know
[13:57:27 CDT(-0500)] <Patty_> how many colors can be assigned to a specific course in map?
[17:06:08 CDT(-0500)] <dmccallum541> i need to switch to unminified js on Linux CI. this cramp anyone's style?
[17:06:58 CDT(-0500)] <TonyUnicon> no
[17:07:48 CDT(-0500)] <dmccallum541> thx. switched
[17:18:30 CDT(-0500)] <TonyUnicon> is there an issue?
[17:18:55 CDT(-0500)] <dmccallum541> 1795
[17:19:47 CDT(-0500)] <dmccallum541> the underlying API call for the details UI, for example is returning 100K results
[17:19:58 CDT(-0500)] <dmccallum541> which qualifies as "too many"
[17:20:05 CDT(-0500)] <dmccallum541> http://ssp-ci/ssp/api/1/reference/journalStep/aba1440c-ab5b-11e1-ba73-0026b9e7ff4c/journalStepDetail?limit=-1&status=ACTIVE&_dc=1380924579363
[17:20:16 CDT(-0500)] <dmccallum541> that'll crash JSONView, for example
[17:22:18 CDT(-0500)] <dmccallum541> there's a buttload of associations for that step in the db (1557), but not that many
[17:23:49 CDT(-0500)] <dmccallum541> heh.
[17:23:56 CDT(-0500)] <dmccallum541> wonder which step we tend to test with...
[17:24:09 CDT(-0500)] <dmccallum541> ssp=# select journal_step_id, count
cnt from journal_step_journal_step_detail group by journal_step_id order by cnt desc;
[17:24:09 CDT(-0500)] <dmccallum541> journal_step_id | cnt
[17:24:09 CDT(-0500)] <dmccallum541> -------------------------------------+-----
[17:24:09 CDT(-0500)] <dmccallum541> aba1440c-ab5b-11e1-ba73-0026b9e7ff4c | 1557
[17:24:09 CDT(-0500)] <dmccallum541> 0a90940a-401b-121b-8140-1bc26d460007 | 8
[17:24:09 CDT(-0500)] <dmccallum541> 0a90940a-401b-121b-8140-1bc248970006 | 6
[17:24:10 CDT(-0500)] <dmccallum541> 0a90940a-4016-1d02-8140-17250f5a0010 | 3
[17:24:10 CDT(-0500)] <dmccallum541> 0a90940a-3ff4-11f8-813f-f417db7b0002 | 3
[17:24:11 CDT(-0500)] <dmccallum541> 0a90940a-3ff0-11f0-813f-f3be88270004 | 3
[17:24:11 CDT(-0500)] <dmccallum541> 0a90940a-4016-1d02-8140-172534b20011 | 3
[17:24:12 CDT(-0500)] <dmccallum541> 0a90940a-412a-163e-8141-2cd5ad610000 | 3
[17:24:12 CDT(-0500)] <dmccallum541> 0a90940a-412a-163e-8141-2cd5e2e60001 | 2
[17:24:13 CDT(-0500)] <dmccallum541> 0a90940a-403e-11bd-8140-402ee0ae0004 | 2
[17:24:13 CDT(-0500)] <dmccallum541> 0a90940a-3efe-1520-813f-00a4d277003b | 2
[17:24:14 CDT(-0500)] <dmccallum541> 0a90940a-3efe-1520-813f-00a4e98f003c | 2
[17:24:14 CDT(-0500)] <dmccallum541> 0a90940a-3efe-1520-813f-00a4ac20003a | 2
[17:24:32 CDT(-0500)] <TonyUnicon> nice
[17:24:38 CDT(-0500)] <dmccallum541> uhoh. freenode just warned me i'm being throttled
[17:25:30 CDT(-0500)] <TonyUnicon> we need to nude that association entity
[17:25:33 CDT(-0500)] <TonyUnicon> nuke*
[17:26:02 CDT(-0500)] <dmccallum541> your first option sounded better
[17:44:35 CDT(-0500)] <TonyUnicon> not sure what the exact cause of it is
[17:44:39 CDT(-0500)] <TonyUnicon> but
[17:44:49 CDT(-0500)] <TonyUnicon> if you're wondering why that screwy logic is in there
[17:45:04 CDT(-0500)] <TonyUnicon> it stems from this mismatch between client and serverside models
[17:45:13 CDT(-0500)] <TonyUnicon> and the 'referencing inactive' issue
[17:52:02 CDT(-0500)] <dmccallum541> well
[17:52:18 CDT(-0500)] <dmccallum541> at the moment i'm just trying to figure out why 1557 db records turns into a 100,000-record JSON payload
[17:52:38 CDT(-0500)] <dmccallum541> i think the 1557 might be demo data insanity
[18:04:13 CDT(-0500)] <dmccallum541> this stuff is insane
[18:04:21 CDT(-0500)] <dmccallum541> (not on you, Tony)
[18:04:51 CDT(-0500)] <TonyUnicon> well partially on me
[18:05:04 CDT(-0500)] <TonyUnicon> but its what happens when you have to build on top of poop
[18:05:14 CDT(-0500)] <dmccallum541> heh
[18:14:39 CDT(-0500)] <TonyUnicon> ok
[18:14:56 CDT(-0500)] <TonyUnicon> I think I know the problem is
[18:15:39 CDT(-0500)] <TonyUnicon> can you give me till monday standup to fix it?
[18:15:48 CDT(-0500)] <dmccallum541> hey. no objection here
[18:16:15 CDT(-0500)] <dmccallum541> not enjoying getting my head back into this little ghetto
[18:16:26 CDT(-0500)] <dmccallum541> and of course my debugger is now refusing to do anything.
[18:16:55 CDT(-0500)] <TonyUnicon> this is my fault in the end, it was hard to notice with my small dataset
[18:17:08 CDT(-0500)] <dmccallum541> i'm opening another ticket to fix the demo data set
[18:17:17 CDT(-0500)] <dmccallum541> it was good in a way
[18:17:27 CDT(-0500)] <dmccallum541> but it's ridiculous for a "demo"
[18:18:44 CDT(-0500)] <TonyUnicon> yeah
[18:18:59 CDT(-0500)] <TonyUnicon> I think if you need 1557 steps to resolve an issue
[18:19:05 CDT(-0500)] <TonyUnicon> it maybe beyond the scope of the app
[18:19:14 CDT(-0500)] <dmccallum541> they're all effectively duplicate associations
[18:19:23 CDT(-0500)] <dmccallum541> they all point to exactly the same detail
[18:20:28 CDT(-0500)] <TonyUnicon> but I think as long as this data model stays as is, there will be a tax on development cost
[18:20:35 CDT(-0500)] <dmccallum541> want to just wipe them out and fix up all the journal_entry_detail records to point at the One True Association
[18:20:36 CDT(-0500)] <TonyUnicon> it made this ordering stuff much more difficult
[18:20:55 CDT(-0500)] <TonyUnicon> probably wouldn't hurt to clean that data up but
[18:20:59 CDT(-0500)] <TonyUnicon> i did notice a mismatch locally
[18:21:03 CDT(-0500)] <TonyUnicon> between the result of that query
[18:21:09 CDT(-0500)] <TonyUnicon> and my json payloads
[18:21:15 CDT(-0500)] <dmccallum541> seems to me it would simpler if this all just routed through the Hib domain model. rather than all the DAOs just for the associations themselves
[18:21:30 CDT(-0500)] <dmccallum541> and of course some client-side model cleanup as well
[18:22:19 CDT(-0500)] <dmccallum541> but almost seems like there needs to be a reboot here, period
[18:23:44 CDT(-0500)] <TonyUnicon> it would be nice to use HQL on that api call
[18:23:52 CDT(-0500)] <TonyUnicon> but then I'd have to write the paging stuff for it
[18:24:18 CDT(-0500)] <TonyUnicon> not that the client cares about paging in these tree models
[18:25:08 CDT(-0500)] <dmccallum541> exactly
[18:26:12 CDT(-0500)] <dmccallum541> for what we actually need it should just be return dao.getStepById(uuid).getDetails();
[18:26:42 CDT(-0500)] <dmccallum541> but i'm sure there's more to it that i'm not thinking of
[18:28:36 CDT(-0500)] <TonyUnicon> its more then that because of object status considerations
[18:28:55 CDT(-0500)] <TonyUnicon> but that old logic did not respect the object status of the association
[18:29:06 CDT(-0500)] <TonyUnicon> only the detail being referenced
[18:29:37 CDT(-0500)] <TonyUnicon> i got a little lazy in that code thinking the data sets were rather small
[18:29:54 CDT(-0500)] <TonyUnicon> but ill replace it with some cleaner code
[18:30:05 CDT(-0500)] <TonyUnicon> how terribly dissapointed would you be if we did not respect the paging?
[18:30:40 CDT(-0500)] <dmccallum541> i can totally live without the paging
[18:30:49 CDT(-0500)] <TonyUnicon> ok
[18:31:08 CDT(-0500)] <dmccallum541> we have no use case where we actually need it. it only exists to prevent user abuse in this case
[18:31:19 CDT(-0500)] <TonyUnicon> i should have it fixed by monday's standup
[18:31:26 CDT(-0500)] <dmccallum541> well, and consistency w/ other APIs. but we've run roughshod over that in other places already
[18:32:57 CDT(-0500)] <TonyUnicon> the beers will go down easy tonight I htink
[18:33:05 CDT(-0500)] <dmccallum541> tell me about it