From 4d352a809bb05023eaeb0669b4aecbd6e5fe926c Mon Sep 17 00:00:00 2001 From: John Cardinal Date: Fri, 1 Jan 2021 23:55:24 +0000 Subject: [PATCH] --- ayanova/devdocs/todo.txt | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) diff --git a/ayanova/devdocs/todo.txt b/ayanova/devdocs/todo.txt index 20c99ba8..75b81388 100644 --- a/ayanova/devdocs/todo.txt +++ b/ayanova/devdocs/todo.txt @@ -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