Evergreen ILS Website

IRC log for #evergreen, 2018-06-27

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:31 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:13 rjackson_isl joined #evergreen
08:13 collum joined #evergreen
08:21 Dyrcona joined #evergreen
08:21 kmlussier joined #evergreen
08:29 bdljohn joined #evergreen
08:46 lsach joined #evergreen
09:04 idjit joined #evergreen
09:12 yboston joined #evergreen
10:03 miker Dyrcona / jeffdavis: sorry, that's incorrect re has_a/might_have/has_many.  I should really write this down somewhere (or find where I have), but:
10:05 miker has_a == any real column on a table or view that can link to another table or view.  normally has an fkey, but not required (a la circ_as_type) and can be nullable
10:07 miker has_many == a virtual field in the IDL that when fleshed will /always/ hold an array of 0-or-more elements pointed at by a link to another class, usually based on the pkey of the local idl class
10:08 miker might_have == the scalar (as opposed to array) version of has_many, it is a virtual field that when fleshed will contain an object (or null) fetched the same way as a has_many relationship type, but taking the first object found
10:10 dbwells miker: Does this jive with the description in the dev docs?: http://library.calvin.edu/devdocs_​project/doku.php?id=start&amp;#idl  It seems to, but maybe there is some subtlety missing for the circ_as_type example.
10:11 Dyrcona I didn't see any difference between has_a and might_have in the code.
10:11 miker dbwells: yes, that description is precisely correct (however, the key field need not be the pkey, per se)
10:12 miker Dyrcona: in what code? because it's very different in cstore et al, but because it's scalar, is used in the same way as has_a in the middle-layer logic
10:13 dbwells miker: I should also find and bug the example that fixme refers to, just to give a place for folks to comment on it.
10:13 Dyrcona oils_sql.c and idlval.c both seem to treat it the same. I saw no reference to the constants in oils_cstore.c when I grepped the code.
10:14 miker mmmm...
10:14 Dyrcona I also looked in Fieldmapper, Storage, and one other place in the Perl code. It's in the logs from yesterday.
10:15 Dyrcona I'm also not really paying as much attention right now as I should.
10:15 * Dyrcona is multitasking poorly.
10:18 miker Dyrcona: so, looking at oils_sql.c around line 6153, it sets up the search for flesh requests the same way for has_many and might_have (as a search against a remote class using the local pkey (side note: pkey /is/ forced today, dbwells, my bad)) but then down at line 6298, after the lookup, it grabs only the first object found, a la has_a
10:20 Dyrcona See, that's the problem: lines 6,153 and 6,298. :)
10:20 miker what's the problem?
10:20 Dyrcona Like I said yesterday, I wasn't making an exhaustive read of the code.
10:21 Dyrcona The line numbers.... They're too high. I'm half-kidding, hence the smiley before.
10:21 miker ah... damn lack of context in text-only conversation :)
10:23 Dyrcona Most of the time I saw things like RT_HAS_A || RT_MIGHT_HAVE so I concluded they were mostly treated the same.
10:23 Dyrcona Anyway, I'm happy to be wrong.
10:25 miker once fleshed (and part of an opensrf transport object) they're semantically identical... it's just the "how do we get them via SQL" that's different. your assumption based on all the non-sql code was reasonable
10:26 Dyrcona Well, I looked at the C code first. I didn't go all the way down to lines 6,000+ in oils_sql.c....
10:26 miker dbwells: so, to answer your FIXME question, it doesn't rely on virtual-ness, it checks reltype. the fixme isn't correct
10:26 miker heh
10:29 dbwells miker: Let me try to clarify what I was getting at.  If you have a second to continue this conversation, take a look at mwps in the IDL.  It is an example of a virtual field with a has_a relationship, which seems counterintuitive to me, since we can't hold a key in a field which doesn't exist.  A vast majority of virtual fields use might_have (or has_many), which seems correct.  But as far as I can tell, might_have/has_a function identically for a
10:29 dbwells virtual fields.  End result, I think this is a source of confusion, and wonder if we should clean it up.  Sorry for the wall of text.
10:31 dbwells I did some experiments on this, but it was a few years back now.
10:33 miker Dyrcona: I have the benefit of having written that logic. :)
10:33 miker dbwells: sec, I'll look
10:34 Dyrcona I'm not sure that's always a benefit. I often don't remember writing the code, never mind how it works. :)
10:35 dbwells My conclusion at that time was something like "has_a" is for real fields, "might_have" is for virtual, an in cases where that doesn't line up, the virtual-ness trumps the reltype (since it seems it can't work any other way).
10:35 Dyrcona Always fun to look at some code and think, "What were they thinking?" only to run git blame and see your name next to it. :)
10:35 miker dbwells: ah! well, mwps is a completely virtual class -- no backing table. the has_a there is just so that the middle-layer code can know from the idl that it's a scalar field rather than an array
10:35 Dyrcona your own name, that is.
10:36 miker Dyrcona: I resemble /that/ as well, as often as not
10:38 dbwells miker: would "might_have" function identically in that case?  I will also poke around and see if I can find another example.
10:39 miker dbwells: IOW, cstore fleshing can't be used for mwps, since there's nothing to select from. that idl class is only used to describe the shape of an object that some middle-layer logic can construct from parts it finds elsewhere
10:39 miker I suppose might_have could work, but if we want to say "you can expect this to always be there" then has_a is closer to the mark
10:41 miker (yes, has_a fields can be nullable ... we probably didn't have oils_obj:required at the time that mwps was invented, though)
10:41 terran joined #evergreen
10:41 miker so, yes, some cleanup would be good
10:42 miker but the fixme isn't correct as far as fleshing via sql is concerned, for sure
10:45 dbwells miker: yeah, I think it would help in that case to reinforce the disassociation of has_a/might_have and nullability, since that is one of the primary issues in forming a mental model on these things.  Thanks for your feedback.
10:48 dbwells miker: and to clarify the fixme, it isn't trying to say current EG does anything wrong, just that it is too permissive in a few cases (IMO).  I think I have one example, but looking for a better one :)
10:58 yboston joined #evergreen
11:11 Christineb joined #evergreen
11:12 dbwells miker: ok, I think this is a good example.  Look at "atb".  All the links are "might_have" (the person was probably thinking nullability), but usr/org/ws certainly know nothing of atb.  But it still works (AFAIK!).
11:14 miker heh ... "the person" ;)
11:14 Dyrcona git blame.... :)
11:14 miker and you may be right, I might have been thinking that. unless I only later edited the lines... unsure
11:15 miker nope, I added that
11:15 * miker hangs head
11:15 dbwells miker: I honestly didn't look!
11:16 * dbwells also skipped one example of something he put in, cause it "wasn't as good of an example" ;)
11:16 miker those def should be has_a. I'm surprised it ever worked properly
11:17 * miker notes that that class is a really good example of more complicated permission setup
11:17 * Dyrcona isn't. :P
11:19 miker maybe they just never get fleshed
11:21 miker yep, that's it. no fleshing. it's used in exactly one place, and the call just filters and orders
11:24 dbwells miker: So maybe the "bug" is just bad data, then.  I've got a little list going here already, so I'll try to finally get some cleanup going on these.  Thanks for the eyeballs.
11:25 miker dbwells: that's what it looks like, yes. IDL just needs fixing. the description on your wiki page does describe what the code actually does (less FIXME)
11:26 dbwells miker: well, the fixme is weasel-worded and surrounded by question marks :)
11:26 miker :)
11:33 Dyrcona So, white screen while saving a patron record apparently lead to the patron being flagged deleted in the database. I will have to check logs for messages (hopefully with object data), but don't hold out much hope.
11:49 khuckins_ joined #evergreen
12:19 jeff dbwells: is there a handy place I could point someone for an example of the Evergreen statement view, short of a demo system?
12:20 jihpringle joined #evergreen
12:21 dbwells jeff: This is one possible place - https://docs.google.com/presentation/d/e/2PACX-​1vTEi2p7zE08HH8xFmKzwMxRm11Zu55Ha8jLgCpTNx5d8HO​qYP3G4cjlgXPgBJhXutqGUepQlG6Z4rl5/pub?start=fal​se&amp;loop=false&amp;delayms=10000#slide=id.g37a39ac221_0_7
12:25 jeff dbwells++ thanks!
12:31 beanjammin joined #evergreen
12:46 kmlussier joined #evergreen
13:01 Dyrcona So, on that user getting set deleted that I mentioned earlier.
13:02 Dyrcona I see an actor card update happening with two extra fields in the object.
13:05 jeff which would probably line up with the auto-appended isnew/isdeleted/ischanged.
13:05 jeff out of sync IDL somewhere?
13:05 jeff or... cached?
13:06 Dyrcona jeff: I don't think the IDL is out of sync, unless it was a bad cached copy on the staff client side.
13:06 Dyrcona This happened on the 11th and they're only reporting it today so we can "fix" it.
13:07 Dyrcona I've fixed the patron in the database.
13:08 Dyrcona open-ils.cstore.direct.actor.card.update {"__c":"ac","__p":["f","REDACTEDBARCO​DE",1808698,REDACTEDUSRID,null,true]}
13:08 Dyrcona I guess the true is the ischanged?
13:09 Dyrcona The null is probably for the isnew or isdeleted? I'm not sure what order they get appended.
13:09 Dyrcona So, I guess that's a red herring.
13:10 Dyrcona But, the patron was set deleted at the same time the above was processed, as far as i can tell.
13:11 jeff i think the order is isnew ischanged isdeleted
13:12 * Dyrcona checks the error log.
13:13 Dyrcona Interesting, the trace turns up errors updating the patron. Specifically a missing mailing address.
13:14 jeff so yeah, i don't see extra fields in that card -- just the expected plus the isnew ischanged isdeleted and isdeleted was omitted because trailing null fields just are.
13:15 Dyrcona Right. I wasn't thinking of the isnew fields when I said that.
13:15 Dyrcona Something definitely went wrong with this update, though. Maybe not the card but some other change they attempted.
13:15 jeff i got it now. i was thinking you saw extra fields which then pushed the new/changed/deleted out of position.
13:17 Dyrcona I'll check the logs on the brick drone where this happened, but I think they've rotated out by now. I can't find any attempt to update the actor.usr itself except for the error about the mailing address in the error log on the syslog server.
13:18 Dyrcona I don't think it's an IDL problem, because if, say, 1 brick had a bad IDL, then I'd expect to get reports for about every 5th patron update or so.
13:18 Dyrcona Not 1 in 4 weeks since the upgrade.
13:19 Dyrcona yeah. logs on the brick don't go back far enough.
13:28 Dyrcona So, I can't say what happened, but I'm sure they didn't delete the patron because the patron was not purged.
13:30 rsulejmani joined #evergreen
14:56 yboston joined #evergreen
15:34 bobt_ joined #evergreen
15:37 bobt_ anyone have time to help me troubleshoot a web staff client issue?
15:49 berick bobt_: probably best to just ask your question.  people will reply as they can
15:56 bobt_ okay. well I have an install of evergreen upgraded from 2.12.6 to 3.1.2 and i can't log into the web client. I get the following errors in the console:
15:56 bobt_ egAuth found no valid authtoken core.bundle.js:1 egStartup.expiredAuthHandler() core.bundle.js:1 successfully connected to offline DB core.bundle.js:1 egNet open-ils.auth.authenticate.init opensrf_ws.js:46 pending count 1 opensrf_ws.js:59 connecting websocket to wss://evergreen-dev.asburyseminary.​edu:7682/osrf-websocket-translator opensrf_ws.js:69 websocket.onopen() opensrf_ws.js:72 pending count 1 Uncaught TypeError: payload.statu
15:59 berick bobt_: can you confirm websockets is running on the server?
15:59 berick i am unable to connect to port 7682 on that host, but that could be firewall-related
16:00 bobt_ Yeah I haven't opened this one externally, but I can navigate to the port 7682 from my browser
16:01 * berick nods
16:01 Dyrcona bobt_: Any segfaults in /var/log/apache2/error.log or wherever the errors for websockets are going?
16:01 berick next confirm open-ils.auth service is running
16:03 bobt_ No segfaults, and open-ils.auth service is running
16:05 bobt_ In the gateway.log I get Received <error> message with type cancel and code 503 whenever I click the sign in button
16:05 khuckins_ joined #evergreen
16:06 Dyrcona Calling 1112
16:06 bshum "So let it be written, so let it be done."
16:06 berick bobt_: that's consistent with the JS error -- and it suggests the client is trying to talk to a service that is not running (or available)
16:06 berick that's the jabber server saying, "there's no one here by that name"
16:10 Dyrcona bobt_: Can you run osrf_contorl --diagnostic on the server?
16:11 bobt_ yes. It shows all services up
16:12 pinesol_green [evergreen|blake] LP1758160_Deleting_patrons_can​_exceed_staff_client_timeouts - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1ebb92b>
16:12 pinesol_green [evergreen|Jason Stephenson] LP 1758160: Bump version in upgrade_log. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5e5f1fd>
16:13 berick bobt_: can you log in elsewhere?  catalog, srfsh, xul client, etc.?
16:14 bobt_ I just tried the catalog and that works.
16:16 collum Oops! How do I delete a branch from the working repository that i accidentally sent?
16:17 bshum collum: I do that all the time, put a colon in front of your branch name.  Like git push working :user/bshum/branchiwantgone
16:18 collum bshum++
16:18 Dyrcona bshum++ # That's what I was going to say.
18:31 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
19:16 pinesol_green [evergreen|Mike Rylander] LP#1773832: Empty deleted records can be surfaced in search results - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=25bd5a7>
19:44 beanjammin joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat