00:00:16.383 --> 00:00:19.468 And then we might it might be useful to do a little training
00:00:19.468 --> 00:00:22.805 on what the async cache does for us as well, and how to use it in
00:00:22.805 --> 00:00:25.233 client project or connector project, whichever.
00:00:27.853 --> 00:00:30.433 Yeah, I mean I I can show you the basic of it.
00:00:30.443 --> 00:00:31.893 I think we got went over it last week though.
00:00:34.843 --> 00:00:40.043 Already have a tiny usage of it and now just cause saved reading
00:00:38.703 --> 00:00:39.323 The house fast.
00:00:40.043 --> 00:00:41.803 from SAGE 100 is slow.
00:00:42.253 --> 00:00:46.323 So I decided to just make reading the product line thing
00:00:46.323 --> 00:00:46.823 cached.
00:00:46.833 --> 00:00:51.628 Because uh, it's not like we support changing the category
00:00:51.628 --> 00:00:52.603 name anyway.
00:00:53.173 --> 00:00:54.973 At least it's not in the workflow so.
00:00:55.753 --> 00:00:56.093 Yeah, sure.
00:00:56.553 --> 00:00:58.133 Yeah, so here is an example.
00:00:58.593 --> 00:01:00.263 So we have this sync provider method.
00:01:00.673 --> 00:01:05.613 Now providers can be created from literally any sync TXVWI.
00:01:08.023 --> 00:01:12.018 There's the P03 for financial charges, the A04 and A08 for
00:01:12.018 --> 00:01:15.540 patient registration and updates, S 1214 and 15 for
00:01:15.540 --> 00:01:19.333 appointment creation and modification and cancellation.
00:01:19.843 --> 00:01:22.883 All those can create new providers at any time.
00:01:24.273 --> 00:01:28.357 So what this thing will do here is we have this async cache of
00:01:28.357 --> 00:01:32.183 string to string so it just looks like a normal dictionary
00:01:32.183 --> 00:01:36.267 from the outside and then when we actually use it here we call
00:01:36.267 --> 00:01:40.482 the get value or generates pass in our key which in this case is
00:01:40.482 --> 00:01:42.103 the MPI or the full name.
00:01:42.673 --> 00:01:46.077 That's just because there's this one special MPI that actually
00:01:46.077 --> 00:01:49.373 represents many different fake doctors like Google and such.
00:01:50.643 --> 00:01:51.433 That's right, I said it.
00:01:51.443 --> 00:01:52.503 Google is not a real doctor.
00:01:54.883 --> 00:01:58.303 So it'll it'll pass that in if it can find a value for that key
00:01:58.303 --> 00:02:01.563 already, it'll just directly return that, no locking at all.
00:02:02.343 --> 00:02:07.847 Otherwise it will lock the semaphore, go into the body that
00:02:07.847 --> 00:02:09.223 you provide it.
00:02:10.563 --> 00:02:12.773 Well, I should say it will lock the semaphore.
00:02:13.043 --> 00:02:16.606 Double check that nobody has added a key since it tried to
00:02:16.606 --> 00:02:19.928 start locking the sun before, since obviously that's a
00:02:19.928 --> 00:02:23.189 possibility, and then it will come into your provided
00:02:23.189 --> 00:02:23.733 function.
00:02:24.283 --> 00:02:27.483 Run whatever logic you need to do to generate your stuff.
00:02:27.803 --> 00:02:30.938 That function just returns like the new value that should be
00:02:30.938 --> 00:02:33.713 cached, and then the entire thing returns that value.
00:02:34.313 --> 00:02:37.690 And obviously anybody else who tries to do this now or who was
00:02:37.690 --> 00:02:41.120 trying to do that when you were locked and inside here will now
00:02:41.120 --> 00:02:42.353 get that value as well.
00:02:45.523 --> 00:02:46.543 And that's it.
00:02:48.263 --> 00:02:50.803 Obviously you have to provide the entire function every time
00:02:50.803 --> 00:02:52.803 or other in every place that you're calling it.
00:02:54.573 --> 00:02:58.327 That would be trivial to make like a either a wrapper of your
00:02:58.327 --> 00:03:01.900 own, or if we actually start running in the cases where we
00:03:01.900 --> 00:03:05.473 need this, we could make like some inherited class of this
00:03:05.473 --> 00:03:08.743 thing that just automatically has that baked into it.
00:03:09.993 --> 00:03:13.819 And yeah, the time being though, I think it's probably going to
00:03:13.819 --> 00:03:17.766 work better, just keep the logic right next to where you're using
00:03:17.766 --> 00:03:21.293 it, since odds are you're probably not going to be reading
00:03:21.293 --> 00:03:25.120 writing from this cache in too many different places, or at the
00:03:25.120 --> 00:03:28.947 very least you can make wrapper method like this that just hits
00:03:28.947 --> 00:03:30.083 the static for you.
00:03:34.483 --> 00:03:34.853 OK.
00:03:35.663 --> 00:03:39.923 And then you said you were using this in their instance.
00:03:35.863 --> 00:03:37.143 Yeah, that's the entire thing.
00:03:39.763 --> 00:03:41.983 Do you step into TXVWI?
00:03:44.633 --> 00:03:44.813 Cool.
00:03:44.833 --> 00:03:48.978 And I think Scarlett said some other client project who's that
00:03:48.978 --> 00:03:53.123 going to already escapes me is already using it for something.
00:03:56.853 --> 00:03:57.823 I think it was an 18.
00:03:57.173 --> 00:03:57.473 Yeah.
00:03:57.483 --> 00:04:02.227 So I have to work out some stuff with the category sync part of
00:04:02.227 --> 00:04:06.379 Nat, but I'm using it just to cash or read just because
00:04:03.313 --> 00:04:03.853 Ah man.
00:04:06.379 --> 00:04:08.603 reading from SAGE 100 is slow.
00:04:10.593 --> 00:04:13.303 So I I suppose I should note.
00:04:13.773 --> 00:04:16.972 Obviously this cache will persist as long as the process
00:04:16.972 --> 00:04:20.396 does, so the process restarts, caches dead, but otherwise it
00:04:20.396 --> 00:04:21.743 will stay there forever.
00:04:22.353 --> 00:04:26.070 There is a method to remove a key though, and then that will
00:04:26.070 --> 00:04:29.361 not error or do anything negative if the key does not
00:04:29.361 --> 00:04:33.079 actually exist, so it's safe to call without having to check
00:04:33.079 --> 00:04:33.993 anything first.
00:04:38.013 --> 00:04:42.009 Obviously if you remove it and somebody else but is in the
00:04:42.009 --> 00:04:46.208 middle of adding it and they add it, that's just gonna get it
00:04:46.208 --> 00:04:46.953 again. But.
00:04:49.003 --> 00:04:52.410 Very sure there's another way to fix that, since the idea of the
00:04:52.410 --> 00:04:55.817 remove here is just to typically just to clear it out so that it
00:04:55.817 --> 00:04:57.023 can be generated again.
00:04:57.173 --> 00:04:57.973 But yeah.
00:05:00.943 --> 00:05:05.904 And then obviously there are overloads in here for, so the
00:05:05.904 --> 00:05:11.371 main one will take a or the key, the cancellation token, and the
00:05:11.371 --> 00:05:14.903 and will output just a task of the value.
00:05:16.203 --> 00:05:19.500 There are overloads as well that will take just a funk that just
00:05:19.500 --> 00:05:22.544 only returns whatever value is supposed to be done, and one
00:05:22.544 --> 00:05:24.573 that doesn't take a cancellation token.
00:05:24.963 --> 00:05:29.933 So you can use whatever you want to use to generate the value.
00:05:38.003 --> 00:05:38.153 Hey.
00:05:40.563 --> 00:05:42.563 This concludes our tour of the ASIC cache.