admin/raven-client
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2021-01-01 23:55:24 +00:00
parent 419e42a44c
commit 4d352a809b
1 changed files with 3 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
ayanova/devdocs/todo.txt
View File

@@ -5,21 +5,10 @@
MISC ITEMS THAT CAME UP
todo: large number of units = timeout on list view
this query painfully slow and times out with huge data:
SELECT COUNT(*) from aunit left outer join acustomer on (aunit.customerid=acustomer.id) left outer join aunit as aparentunit on (aunit.parentunitid=aunit.id) left outer join aunitmodel on (aunit.unitmodelid=aunitmodel.id) left outer join avendor on (aunit.purchasedfromvendorid=avendor.id) left outer join aunit as areplacedbyunit on (aunit.replacedbyunitid=aunit.id)
This query:
SELECT COUNT(*) from aunit
left outer join acustomer on (aunit.customerid=acustomer.id)
left outer join aunit as aparentunit on (aunit.parentunitid=aunit.id and aunit.parentunitid<>null)
left outer join aunitmodel on (aunit.unitmodelid=aunitmodel.id)
left outer join avendor on (aunit.purchasedfromvendorid=avendor.id)
left outer join aunit as areplacedbyunit on (aunit.replacedbyunitid=aunit.id and aunit.replacedbyunitid<>null)
Super fast no timeout
todo: Join filters make a huge difference in speed of datalist queries (and anything else when working with huge data)
check into all datalist and picklist queries with joins at the server and if the joined table is optional (foreign key null possibility) then add a join condition
(left join blah where main.blahid = blah.id and main.blahid is not null)
todo: Notification at server has NotifyDeliveryLog object unused and no UI at from for it either
it's supposed to keep a set queue of the past 90 days of deliveries for troubleshooting like in v7,
@@ -27,6 +16,8 @@ todo: Notification at server has NotifyDeliveryLog object unused and no UI at fr
and no ui to view them?!
figure it out
todo: do not compare null in queries so double check and instead make sure it's using "Is not null" or "is null" instead as results are non determinant otherwise
todo: unitmodel, maybe can make a combo unique constraint for the model number or name by combining with the vendorID
it's doubtful two models from the same vendor would have the same model number so this covers that case or am I wrong on that?
purpose of this is to catch duplicate entries while still supporting duplicate model numbers