Hi Dmitri, thanks for checking the doc out. Indeed, in this implementation, the server does not apply any "decision logic" at all to the commits. Or perhaps it's more accurate to say that the decision logic applied is only to inspect the commits and check for their mutual consent to deconflict. The server trusts this mutual consent.
There's a small section about other strategies at the end of the doc -- essentially, I think we could implement various deconfliction strategies and allow them to be mixed together, like we do with the FileIOFactory implementations for example. --EM On Mon, Jul 7, 2025 at 3:57 PM Dmitri Bourlatchkov <di...@apache.org> wrote: > Hi Eric, > > This sounds like an interesting approach to me. > > I wonder how much decision logic do you envision Polaris to perform for > de-conflictling? Is it mostly approving based submitted "Writer" ID checks > or will Polaris validate actual table changes? > > I added some comments to the doc too. > > Thanks, > Dmitri. > > On Mon, Jul 7, 2025 at 6:33 PM Eric Maynard <eric.w.mayn...@gmail.com> > wrote: > > > Hi all, > > > > Wanted to share this short design doc > > < > > > https://docs.google.com/document/d/1tkqBOYtkcA7fbDmhIAE6_6Jmus5WwP6vS6jA_JHp4Ms > > > > > for > > a simple method of allowing conflicting commits to both be committed. If > > implemented, this would allow e.g. two writers doing append-only > operations > > to a table in Polaris to always succeed. > > > > If you're interested, please take a look. In the meantime, I'll be > > preparing a small draft PR to serve as a reference implementation. > > > > --EM > > >
