I don't think that Polaris should change any view definition in any way,
but this is what the proposed approach does.
The approach breaks the contract (behavior defined by the specification)
and in turn the observed behavior, absolute no go's.
Practically speaking, the approach is blindly cha
There's no notion of "snapshot" or "nightly" for image tags. That's why
we're pushing for the separate repos.
On 20.05.25 05:18, Jean-Baptiste Onofré wrote:
Yes agree. Latest would be a valid tag only for release images.
Snapshot images will be just … snapshot tag ;) (not latest).
Regards
JB
I wouldn’t say that Polaris is changing a view definition, but per my
understanding Polaris is actually generating a view based on a Policy.
We will need a way for Polaris to embed some information into these views.
I don’t think this is a P0 to make FGAC work, and I don’t think this
necessarily n
Looks awesome. Thanks for taking the lead! It makes sense to use a
JDBC-backed persistence layer, shared or separate. The optional retention
period is a nice safeguard.
I don’t see any blockers on my side. If no one raises major concerns this
week, please go ahead and start the implementation. Exci
Hi Prashanth,
I looked at the use cases you are trying to solve. Would having RBAC on the
view solve them?
Taking your example,
CREATE VIEW dynamic_vw ASSELECT *FROM ns1.layer1_tableWHERE
is_principal_role('ANALYST');
Can't this be solved by simply having the view as,
CREATE VIEW dynamic_vw AS
Hey Keith,
For this case it does, but if you see what if i want to define something
like this
CREATE VIEW dynamic_vw AS SELECT *FROM ns1.layer1_table WHERE
is_principal_role('ANALYST')
OR IS_MEMBER() <- Random UDF or JOIN;
Now if i don't have access to view since my principal is ANALYST i will
> Let's work together on a proper design.
For sure ! will be reaching out soon for this !
Best,
Prashant Singh
Hi
Yes: no shaded jar artifacts on Maven repository.
On maven repository you will find the same tar.gz/zip as on dist. The other
jars are “regular” jar files.
Regards
JB
Le mar. 20 mai 2025 à 17:19, Ryan Blue a écrit :
> JB, can you please confirm that there should be no shaded binaries in th
Yes but we can use tag that way “by convention”.
Le mar. 20 mai 2025 à 10:18, Robert Stupp a écrit :
> There's no notion of "snapshot" or "nightly" for image tags. That's why
> we're pushing for the separate repos.
>
> On 20.05.25 05:18, Jean-Baptiste Onofré wrote:
> > Yes agree. Latest would be
Thanks Ryan
If the helm chart tarball name is not a blocker, the license there is.
We have to fix that.
I will cancel rc3 to fix helm chart license and notice.
Thanks
Regards
JB
Le mar. 20 mai 2025 à 22:10, Ryan Blue a écrit :
> Mostly checked licenses. There were a couple of minor issues:
>
+1 (binding)
1. Verified checksums
2. Verified build/test from source distribution
3. Verified server binary distribution
On Mon, May 19, 2025 at 2:40 PM Yufei Gu wrote:
> +1(binding)
>
> 1. Verified asc, sha512.
> 2. Build and test passed.
> 3. Verified both binary distributions, admin and ser
Hey Robert,
I believe you are quoting Iceberg view spec :
https://iceberg.apache.org/view-spec/#versions
1. All representations for a version should express the same underlying
definition (This holds true )
2. Immutable View versions : if the concern is that we are using the same
view version, we
JB, can you please confirm that there should be no shaded binaries in the
staged maven repository? Any context like this you can give us will help
when reviewing the licenses for this release. For example, if the helm
chart tarball doesn't contain third-party code that would be helpful to
know.
On
Ah, I misunderstood that this applies only to views generated based on an
FGAC policy. On this point I agree -- we probably don't want to change VIEW
definitions, or at least we need to be very cautious about doing so. Let's
not put this on the critical path for FGAC views.
--EM
On Tue, May 20, 2
Mostly checked licenses. There were a couple of minor issues:
- The helm charts tarball doesn't include "polaris" in the name.
- The helm charts tarball includes at least one file (_helpers.tpl) with a
Dremio copyright header that isn't documented in the LICENSE file
On Tue, May 20, 2025 at 10:09
As I mentioned in my previous reply:
"FGAC is a very complex topic. The right way would be to have a holistic
design and agreed-on approach. That does take time."
The proposed approach changes the observed behavior. It makes it
impossible to change the view later on. Plus the other concerns I
This proposal _does_ change the view definition - it returns a
_different_ representation than the one that has been stored before.
This is a change that breaks the contract of the specification and it
changes the observed behavior.
FGAC is a very complex topic. The right way would be to have
+1
1. Verified Cheksums, Build, run
Server - Dist:
Checked licences and notices in all Jars
Everything looks the same as on the PR we did for RC2 to fix up licenses
I saw notices that still had dual licenses but the text looks
directly copied and both licenses are green (Apache + Ecli
Thanks Russ.
I updated the main license file but forgot to update in helm chart. I have
to fix that.
For dual license I did a pass but I have to missed some.
Regards
JB
Le mar. 20 mai 2025 à 19:44, Russell Spitzer a
écrit :
> +1
>
> 1. Verified Cheksums, Build, run
>
> Server - Dist:
>Chec
I don't think it's an issue (for dual license) because it's in the "Must
copy this notice" text which says this code is licensed under this & that
On Tue, May 20, 2025 at 1:57 PM Jean-Baptiste Onofré
wrote:
> Thanks Russ.
>
> I updated the main license file but forgot to update in helm chart. I
That’s super interesting. Glad this is being worked on. Personally, I don’t
know that the latency for writing events to a persistent storage is really
all that concerning. Looking at the enum of supported operations, only
write operations seem to trigger the event. It’s not like every read
request
Hi Adnan,
That is a really interesting and important work! Implementing event storage
through persistent backers totally makes sense to me.
For the event buffer, I think it is great to batch the events and reduce
access to persistence. However, I am wondering if durability
during service start is
Hmm, we do use the realm tag in our metric publishing. I understand the
concern re: cardinality. Maybe we can support filtering metrics that have
realm and support another metric without realm?
On Mon, May 19, 2025 at 12:24 PM Dmitri Bourlatchkov
wrote:
> Removing realm_id from metrics tags make
23 matches
Mail list logo
