For requests or help with our API
-
joergzastrau
- Posts: 46
- Joined: Sun Feb 27, 2022 2:53 am
Post
by joergzastrau » Wed Mar 02, 2022 12:30 am
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
-
SLeon
- Posts: 583
- Joined: Mon Mar 01, 2021 10:00 am
Post
by SLeon » Wed Mar 02, 2022 3:48 pm
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.
-
jordansparks
- Site Admin
- Posts: 5770
- Joined: Sun Jun 17, 2007 3:59 pm
- Location: Salem, Oregon
-
Contact:
Post
by jordansparks » Thu Mar 03, 2022 10:38 pm
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.
-
joergzastrau
- Posts: 46
- Joined: Sun Feb 27, 2022 2:53 am
Post
by joergzastrau » Sun Mar 06, 2022 10:25 am
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.
-
jordansparks
- Site Admin
- Posts: 5770
- Joined: Sun Jun 17, 2007 3:59 pm
- Location: Salem, Oregon
-
Contact:
Post
by jordansparks » Sun Mar 06, 2022 1:41 pm
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.