> I will be asking you to think about locking and if/how it will be possible to implement DB links type through a JSON link.
Not for 3.16.1. I'm going to draw a line at making further changes to lockset code for this release.
From your prospective, a hard requirement will be that all involved records be known when dbParseLink() returns. I see no way to relax this without introducing tremendous complexity (eg. higher level fail and re-try). So the fact that there are no link support callbacks before dbSetLink() seems like a show stopper for changing lock sets.
In general I'd like to see more validation in dbParseLink() as this is the point where such errors can be failed cleanly. Forgetting the '@' w/ INST_IO is easy. I see typos in json strings being even more common. I'm sure you won't like the idea of parsing twice, but I see this as worthwhile trade off.
> I have implemented the "remaining work" you itemized
> I will be asking you to think about locking and if/how it will be possible to implement DB links type through a JSON link.
Not for 3.16.1. I'm going to draw a line at making further changes to lockset code for this release.
From your prospective, a hard requirement will be that all involved records be known when dbParseLink() returns. I see no way to relax this without introducing tremendous complexity (eg. higher level fail and re-try). So the fact that there are no link support callbacks before dbSetLink() seems like a show stopper for changing lock sets.
In general I'd like to see more validation in dbParseLink() as this is the point where such errors can be failed cleanly. Forgetting the '@' w/ INST_IO is easy. I see typos in json strings being even more common. I'm sure you won't like the idea of parsing twice, but I see this as worthwhile trade off.
> I have implemented the "remaining work" you itemized
Ok, I'll give it a shot.