Page 1 of 1
API: high/duplicate AptNum returned by Appointments GET (multiple)
Posted: Wed Mar 02, 2022 12:30 am
by joergzastrau
Hello,
a question about recent appointments in the public OD test installation. The query
Code: Select all
"https://api.opendental.com/api/v1/appointments?Limit=10&dateStart=2022-03-02&DateTStamp=2017-02-08 09:40:20"
returns
Code: Select all
{
"AptNum": 4908068889037505000,
"PatNum": 373,
"AptStatus": "Scheduled",
[..]
Code: Select all
"AptDateTime": "2022-03-22 08:00:00",
[..]
Code: Select all
"DateTStamp": "2022-03-01 23:59:05",
"serverDateTime": "2022-03-02 00:05:13"
}
The AptNum is in use for multiple other entries and appear large. Early entries start with unique single digit numbers. Is this intentional?
With best regards
Joerg
Re: API: high/duplicate AptNum returned by Appointments GET (multiple)
Posted: Wed Mar 02, 2022 3:48 pm
by SLeon
We are in the process of switching to a new demo dental office database for our testing credentials. You will soon see smaller primary keys for some of our tables, such as appointments.
Re: API: high/duplicate AptNum returned by Appointments GET (multiple)
Posted: Thu Mar 03, 2022 10:38 pm
by jordansparks
But it's always possible for patient databases to have extremely large primary keys. You need to be able to handle them, even if they are large. In C#, the type is long, and in mysql, the same type is called bigint. It can have a max of 9,223,372,036,854,775,807.
Re: API: high/duplicate AptNum returned by Appointments GET (multiple)
Posted: Sun Mar 06, 2022 10:25 am
by joergzastrau
The MAX_SAFE_INTEGER in JS is 2^53-1. Considering the maximum number of possible patients to be equal to the number of persons living on earth then I would like to mention that the AptNum being 64 Bit poses a problem to me.
Re: API: high/duplicate AptNum returned by Appointments GET (multiple)
Posted: Sun Mar 06, 2022 1:41 pm
by jordansparks
We settled on this about 15 years ago. It allowed different ranges of PKs for different offices all using the same database with replication, so that there was virtually no chance of collision. Also, many tables such as logs can fill up rather quickly. It's something that must be intentionally turned on by the office, and I suspect that virtually nobody is using it, but it is a possibility. It's also possible that, if an office does have large PKs, that we could somehow "repair" their database and convert them all to smaller PKs. Hopefully, it won't come to that. Also, JS does have bigint.