| Time |
Nick |
Message |
| 01:12 |
|
abneiman joined #evergreen |
| 01:12 |
|
akilsdonk joined #evergreen |
| 01:12 |
|
phasefx joined #evergreen |
| 07:21 |
|
collum joined #evergreen |
| 07:26 |
|
kworstell-isl joined #evergreen |
| 07:29 |
|
BDorsey joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 09:00 |
|
Stompro joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:28 |
|
terranm joined #evergreen |
| 09:30 |
terranm |
Good morning, all. I have a question about creating views. There are some that are created on the PostgreSQL side and referenced like any other table in the fieldmapper, and there are some that are created by adding the SQL to the fieldmapper instead. Are there reasons why one is better practice than the other, or does it depend on what it will be |
| 09:30 |
terranm |
used for? |
| 09:31 |
* mmorgan |
has often wondered that also. |
| 09:32 |
mmorgan |
There is also SQL in the perl code, so that's another place. |
| 09:35 |
Dyrcona |
I've never heard/seen a rationale for creating views in the database versus using SQL queries in the IDL as if they were views. I think the big difference is views are available in the database via SQL, and IDL queries are not. |
| 09:39 |
terranm |
So I guess if you are just creating a view for use by say, reports, then plopping it in the fieldmapper would be fine, but if it will need to be accessed by different functions, then adding it on the db side would be better. I wonder if there are any performance differences? I guess if it were on the db side then it could be indexed? (I'm out of my |
| 09:39 |
terranm |
depth there.) |
| 09:41 |
|
kmlussier joined #evergreen |
| 09:41 |
mmorgan |
I have also wondered if there is any difference in efficiency. My gut says the db side should be more efficient - but I'm also a bit out of my depth :) |
| 10:09 |
|
kmlussier joined #evergreen |
| 10:09 |
|
dguarrac joined #evergreen |
| 10:12 |
terranm |
Dyrcona++ mmorgan++ |
| 10:17 |
Dyrcona |
There's probably not much difference in efficiency. You can write bad joins in either case. |
| 10:18 |
terranm |
Well, *I* can certainly write bad joins :) |
| 10:19 |
Dyrcona |
I have a hard time with the reporter. I can write the equivalent SQL with ease, and it's fast. If I try to do it through the reporter interface, I almost always end up joining the tables wrong and the query is very slow. |
| 10:23 |
terranm |
The way nullability is used in the reporter is really confusing. It would be easier if it just said what type of join it was creating. |
| 10:44 |
jeff |
I favor creating views in the database, because we do all of our reporting via SQL. |
| 10:45 |
jeff |
(and our hold pull lists, etc) |
| 10:49 |
Dyrcona |
Yeah, I would favor views in the database for the SQL access, and you can add them as readonly sources in the IDL, just specify the view for the table name. |
| 10:51 |
|
BrianK joined #evergreen |
| 11:10 |
|
Christineb joined #evergreen |
| 11:33 |
|
kworstell-isl joined #evergreen |
| 11:59 |
|
jihpringle joined #evergreen |
| 12:12 |
|
collum joined #evergreen |
| 12:22 |
terranm |
Thanks! |
| 12:34 |
|
collum joined #evergreen |
| 12:36 |
|
collum joined #evergreen |
| 12:43 |
jonadab |
100% agree about joins in the reporter. |
| 12:44 |
jonadab |
They confuse me in ways that SQL would not. |
| 12:45 |
terranm |
Same |
| 12:45 |
jonadab |
And if there's a way in the reporter to do the equivalent of a sub-SELECT, I haven't found it. |
| 13:00 |
Dyrcona |
I shall return in an hour or so. |
| 13:43 |
|
sleary joined #evergreen |
| 14:09 |
|
mantis joined #evergreen |
| 14:10 |
mantis |
just installed 3.9.4. Has anyone gotten this error when trying to upload a Marc order file? |
| 14:10 |
mantis |
2002:Database query failed > the attempt to query to the DB failed |
| 14:11 |
mantis |
'check Import non matching records and Merge on best match. Record match set should be Matchpoint and Merge profile should be Match only merge' |
| 14:20 |
jeff |
My first step would be to check the database logs to see what the error was, if any. Usually there will be one in the case of a "Database query failed" error in the UI/console. |
| 14:21 |
jeff |
(Others here might chime in with a common issue that you might be running into in this specific case, in which case you might not actually need to pull the error from the database server logs.) |
| 14:28 |
mantis |
initially when I load the page, there were errors when reading the AutoFieldWidget.js file |
| 14:28 |
mantis |
those don't have a change in it |
| 14:29 |
mantis |
wondering if there was an issue when I refreshed our db before the install... |
| 14:34 |
|
jihpringle joined #evergreen |
| 14:52 |
|
Dyrcona joined #evergreen |
| 15:02 |
|
mantis left #evergreen |
| 15:18 |
mmorgan |
mantis: That sounds familiar with a fresh install. I think we had to set a couple library settings. We set them to True for the CONS: 'Upload Import Non Matching by Default', 'Upload Merge on Best Match by Default' |
| 15:22 |
|
kworstell-isl joined #evergreen |
| 15:43 |
|
jihpringle joined #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 18:50 |
|
brian__ joined #evergreen |
