| 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&#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-1vTEi2p7zE08HH8xFmKzwMxRm11Zu55Ha8jLgCpTNx5d8HOqYP3G4cjlgXPgBJhXutqGUepQlG6Z4rl5/pub?start=false&loop=false&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","REDACTEDBARCODE",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 |
