Tomasz Lelek

@snazy I am not sure why do we need this step: ``` in spark-extensions and spark32-extensions poms unpack the source of the new "spark-extensions-common" module to a separate folder underneath...

> You need to unpack it to extract the common source files. Yes, but why we can't share the code as a normal maven dependency? This is in the same...

My findings. We have two sources of duplication. **The first one** is in the `plans.logical` package of both `spark-extensions` and `spark-3.2-extensions`. All the `*Commands` are case classes that are built...

Couple questions (@snazy): - do we want to support the ~X (i.e.: `HEAD~10`) syntax and ^ (i.e.: `HEAD^`) syntax or only the former? - regarding the signature that you gave:...

What about the rest of the questions? What do we want to support?

>stick with CEL and do it on the client side for now @snazy can you elaborate more on that? Do you mean we can handle that also via `filter` or...

I am opening this as a draft PR to discuss if the changes are in the right direction. Right now I modified only `QueryBuilder.selectFrom` to make it work for keyspace...

One more question @mp911de. The logic for `do*Versioned` is emitting events like for example: `maybeEmitEvent(new AfterSaveEvent(entityToSave, tableCoordinates.getTableName()));` and: ``` public AfterSaveEvent(E source, CqlIdentifier tableName) { super(source, tableName); } ``` It...

> Let's keep events and entity callbacks for a future step in mind so we don't change these yet. What do you mean by the future step? Do you want...

question regarding testing: I would like to add tests for all `*OperationSupport` classes that are working now per TableCoordinates, and also have a new method: `UpdateWithQuery inTable(CqlIdentifier keyspaceName, CqlIdentifier tableName)`...