Skipping the 0.10.0 release and going for 1.0.0 sounds good to me.
Cheers,
Dmitri.
On Fri, Jun 6, 2025 at 6:49 PM Jean-Baptiste Onofré wrote:
> Hi everyone,
>
> As you know, due to the JDBC issue, we cancel the
> 0.10.0-beta-incubating rc4 release vote.
>
> After investigating and discussing wi
+1, as I understand it the role of 0.10 was to get us ready for a release
with binaries and to that end it has served its purpose. We're now 1.0
ready thanks in large part to the work done to make 0.10 happen even if
there winds up being no actual 0.10 release.
On Fri, Jun 6, 2025 at 4:00 PM Prash
+1 on skipping 0.10 and releasing 1.0 directly given the current status. We
don't have to spend more time on 0.10.0-beta, and 0.10.0-beta is an
experimental release, not supposed to be used by users. There would be less
confusion on the users side, if we cancel it now.
Yufei
On Fri, Jun 6, 2025
+1 on skipping 0.10 since we are very close to closing all 1.0 blockers.
Best,
Prashant Singh
On Fri, Jun 6, 2025 at 3:57 PM Yufei Gu wrote:
> +1 on skipping 0.10 and releasing 1.0 directly given the current status. We
> don't have to spend more time on 0.10.0-beta, and 0.10.0-beta is an
> expe
Hi everyone,
As you know, due to the JDBC issue, we cancel the
0.10.0-beta-incubating rc4 release vote.
After investigating and discussing with Prashant, 0.10.0 rc4 release
was NOT impacted by the SQL injection issue:
- the "vulnerable" code is in extension/persistence/relational-jdbc
module (in
Hi guys
About FGAC, I think we have to be more pragmatic.
We can identify three parts in FGAC:
- column masking
- column filtering
- row filtering
I believe the easiest to start with is column masking.
Let's start with column masking. The cinematic would be:
1. The query engine calls the catalo
In terms of achieving this I was thinking of this as the following as well
:
1. role based column filtering as -> This should be achievable, without a
lot of lift shift.
2. simple row based filters
3. column mask and row mask (when Iceberg UDF are established)
And agree we just need to store the ma
It seems to me that the *easiest* to start with would be role-based column
filtering. There are no functions to grapple with, no dialect differences.
You simply grab the list of columns that a given principal role has access
to according to the FGAC policy attached to a given table.
--EM
Agreed with Alex. I think passing a realm context is a cleaner solution
than injecting a request scope realm context. CDI provides a lot of
benefits, but it doesn't mean that we should alway use it.
In general, injecting a request-scoped bean into an application-scoped bean
is perfectly valid in C
Thanks, Alex! Very good points!
Re: metrics, I did a quick POC by adding `@Inject RealmContext rc`
to QuarkusValueExpressionResolver and it appears to work. That
is, QuarkusValueExpressionResolver can get the realm ID from the injected
RealmContext as opposed to the API parameter.
With that, we c
Hi Dmitri,
Thanks for bringing up this important topic.
I generally agree with your refactoring proposal, but with 2 caveats:
1) For an application-scoped bean exposing methods to retrieve realm-scoped
components (e.g., the "factory" beans that expose methods like
"getOrCreateXYZ") I think it's
11 matches
Mail list logo
