no changes, just moved from kernel/src/transaction.rs

now in #386

When you say "overwrite isn't used for the existing commit flow", does that mean that overwrite will not sidestep the PutIfAbsent? If so, I think that could be clarified a bit.

hm. all i mean to say is that we don't actually use this param yet. (will be used in the future to support writing _last_checkpoint)

Nit: This is a bit much, but if fields()'s signature was changed to return a DoubleEndedIterator, you can also avoid materializing this, use next_back, and remove the into_iter down below. Tho I imagine action_fields is pretty small anyway.

                    let mut action_fields = get_log_schema().fields();
                    let commit_info_field = action_fields
                        .next_back()
                        .expect("last field is commit_info in action schema");
                    //...
                    let action_fields = action_fields.cloned().chain(std::iter::once(
                        crate::schema::StructField::new(COMMIT_INFO_NAME, commit_info_schema, true),
                    ));
                    StructType::new(action_fields.collect())

haha nice I like this and will keep open to consider in the future but probably punting on it in this PR?

I think you can setup tracing using #[test_log::test(tokio::test)] and avoid the try_init. Relevant docs for test_log

hm I'm curious on peoples' thoughts on this.. seems like the init is a simple step but maybe it is nice to use test_log? I haven't been using it since it feels clearer for me to use typical #[tokio::test] and just to manual init

aside: Does object_store support the new S3 put-if-absent capability?

good question! theres a recent issue but I haven't followed up much yet on it: apache/arrow-rs#6285

Out of curiosity, why does this need a lifetime specification?
It doesn't outlive the method call and isn't ever passed to any async code?

also: can we get away with this as a workaround?

Lifetime specification is since it defaults to 'static and we don't want to impose that requirement. seemed odd to me that it would default to static but didn't take too much time to dive into it yet. and secondarily I think if we use impl Iterator it causes the trait not to be object-safe

aside: I'm surprised cargo fmt didn't add a trailing comma here (and again below)?

interesting. just reran it looks like you're right: it doesnt

Aside: Does this handle {:#?} formatting?
(I've been wondering how custom Debug would work in that case, ever since learning about it)

this specific implementation doesn't but it is all handled in the Debug trait via Formatter's alternate(). if we wanted to handle pretty printing it would be something like

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
    if f.alternate() {
        // Pretty-print formatting when using {:#?}
    } else {
        // Normal formatting
        f.write_str(...);
    }
}

If we don't want people to use it, can we just make it private?

sure probably makes sense to implement a smaller API for now and open this up if people ask for it?

(made pub(crate))