>
> Spec is an interesting topic we did not discuss. Robert, how do you
> envision this to be used?
> In my mind, if a new table format v3 is launched, there are 2 approaches
> we can go with, taking CreateTable as an example:
> (1) increment the related operation version, which means that POST
>
>
> My personal solution to this is to add a request context, which was
>> prototyped in https://github.com/apache/iceberg/pull/10359. With this,
>> an engine can describe the privileges needed when requesting table
>> metadata. The prerequisite is that the catalog trusts the information
>> passed
Oh - I'm not against having the fine(r) grained privileges per se. Just
saying that it's at best quite complicated to enforce those "properly".
The "trust" model probably deserves a separate (but related) discussion.
There are potentially different "kinds" of how one can implement trust.
Some
Should we vote on this deprecation? As we said in the sync meeting, we do
not want to make decisions in that meeting, all such proposal decisions
should be made on devlist.
-Jack
On Tue, Jul 2, 2024 at 1:03 AM Robert Stupp wrote:
> Summary of the REST-sync meeting yesterday, comments welcome:
Yes I am totally aware of the situation of people on vacation and
traveling, and was in the process of talking and resolving some people's
comments in the doc, that's why I did not start the vote as originally
planned. I think we are all aligned on this, sorry I did not make it very
clear in the
Thanks Owen, I really appreciate the offer to moderate the discussion. I
think that's a good idea and it would really benefit the community to have
someone facilitating the discussion and drafting docs that does not have
commercial interest.
A number of PMC members have expressed that they're
> For INSERT/UPDATE/DELETE/TRUNCATE - well, that is really tricky for the
reasons how writes happen in Iceberg.
Yes. It seems like we are arriving at the conclusion that it is easy to
have a simple verb for all data write operations, we can call it UPDATE or
MODIFY or WRITE_DATA. The ability to
The opposite is, as I expressed, that a client would _not_ use
functionality that worked before. In other words: the
capabilities-change would become a _breaking_ change - not backwards
compatible.
On 02.07.24 15:02, Eduard Tudenhöfner wrote:
I couldn't make it to the catalog sync meeting
I think that we really need to let a service express which
table/view/udf/etc-spec versions it supports. Otherwise, as you noted, a
client would only receive some error. If a "table-spec v4" aware client
knows that the service just knows about "table-spec v2", it can just use
that version -
Spec is an interesting topic we did not discuss. Robert, how do you
envision this to be used?
In my mind, if a new table format v3 is launched, there are 2 approaches we
can go with, taking CreateTable as an example:
(1) increment the related operation version, which means that POST
I couldn't make it to the catalog sync meeting yesterday but I watched the
recording today (thanks for providing that).
The missing piece is how (new, capabilities-aware) clients handle the case
> when a service does _not_ return the capabilities field (absent). My
> proposal would be that a
Just some thoughts about "SELECT vs DESCRIBE": If a catalog can
distinguish these privileges, it can opt to return the manifest list
pointer only, if the caller has the SELECT privilege.
For INSERT/UPDATE/DELETE/TRUNCATE - well, that is really tricky for the
reasons how writes happen in
Hey everyone, thanks for jumping in here.
On the run Flink without Hadoop PR, I've removed it from the milestone
since after discussing with Peter on the PR, we've agreed that there needs
to be a more fundamental fix. Also, it would be good to have tests to
ensure that it runs without Hadoop.
Hi Amogh
Thanks for your help in the PRs !
I will do a new pass as well (as said in my previous email).
Regards
JB
On Mon, Jul 1, 2024 at 11:09 PM Amogh Jahagirdar <2am...@gmail.com> wrote:
>
> Thanks JB and Robert for following up on this, I'm taking a look at the PRs
> in the current
Hi Robert,
I gonna take a look. As I'm working on the Avro releases with Fokko, I
think it's OK to take a few more days for 1.6.0 release preparation
(especially with July 4th this week).
So, let me do a pass on these issues (and work on it if needed ;)).
Thanks !
Regards
JB
On Mon, Jul 1,
Hi Owen
Sorry I missed your message before replying. I agree, I think we
should take more time on the proposal.
Regards
JB
On Mon, Jul 1, 2024 at 10:14 PM Owen O'Malley wrote:
>
> Sorry for coming into this conversation late, but I have a lot of experience
> with writing the bylaws for Apache
Hi Jack,
I don't think we are ready for a vote already: the document has still
comments to be discussed imho.
I would give more time to everyone to take a look.
Generally speaking, if I understand the overall idea, I see a lot of
content similar to the ASF resources (so maybe just referencing
Summary of the REST-sync meeting yesterday, comments welcome:
There were no objections to the PR for M1 (deprecation of the endpoint
in the spec). The only comment was to deprecate the oauth schema types
as well. This has been integrated in the PR.
A concern was raised that it's convenient
We also talked briefly about whether clients/server must fail on unknown
attributes/values or not. Please correct me if I'm wrong, but I think
that the consensus in the meeting yesterday was clients must fail.
(more comments inline below)
On 02.07.24 04:44, Jack Ye wrote:
Each operation will
19 matches
Mail list logo
