Good idea. I will add a section about that.
Regards
JB
Le mar. 27 mai 2025 à 18:38, Russell Spitzer a
écrit :
> You could add in some of the events that have been hosted recently, I know
> you presented at them :)
>
> Might also be nice to list some of the recent proposals brought to the
> comm
I meant 17 messages from new users. Let me add new slack users metric.
Thanks !
Regards
JB
Le mar. 27 mai 2025 à 18:11, Yufei Gu a écrit :
> Thanks JB for doing this.
>
>
> > On Slack, since March, we have 17 new users.
>
> Here are new users for Apache Polaris slack workspace
> 1. March: 53
It was a mistake from my part while svn commit on dist due to
https://github.com/apache/polaris/issues/1676: i had to re-sign artifacts
for dist.
With 1676 fixed we will be fine for next releases.
Regards
JB
Le mar. 27 mai 2025 à 17:44, Ryan Blue a écrit :
> JB, what happened here? Is there a
The thing is that IntelliJ, for example, does not infer @Nullable very well.
For example:
Map m = new HashMap<>();
private @Nullable String value() {
return m.get("key");
}
private void test() {
String value = value();
if (value.length() > 3) {
m.put("key", value);
The concern, for me, is whether the onus is on the developer or on the
tools. For example, if I write a method:
public String getTheValue() { return map.get("value");}
with no annotation, the assumption is the return value of getTheValue is
always non-null even though java.util.Map does not make
That location is fine, although I do not really see why contributing to
Persistence should be any different from contributing to other areas of
Polaris code.
Cheers,
Dmitri.
On Tue, May 27, 2025 at 7:03 PM Yufei Gu wrote:
> Dmitri, we could place it along with existing contribution guidelines,
Dmitri, we could place it along with existing contribution guidelines,
https://polaris.apache.org/community/contributing-guidelines/, but I'm open
to suggestions.
Yufei
On Tue, May 27, 2025 at 2:10 PM Dmitri Bourlatchkov
wrote:
> Hi Yufei,
>
> I posted some comments in the doc.
>
> Where do yo
If we've checked something is non-null or received a non-null value from a
library, we can continue annotating it as @Nonnull within Polaris. We can
also use Optional to get similar functionality to typescript's ? and handle
missing values that way.
In all other cases, developers must assume any g
Right, but I think Michael is correct that when something comes from
outside of Polaris, we have to assume it’s nullable even if it’s not
annotated as such.
Also as we are using CDI, it may not be clear whether an implementation of
an interface is coming from “Polaris code” and therefore what assu
Yes, the idea is to simplify things by using only one of @Nullable
and @Nonnull in Polaris code.
However, I lean toward using @Nullable when necessary and assume @Nonnull by
default. Again this is only for Polaris code.
Cheers,
Dmitri.
On Tue, May 27, 2025 at 5:07 PM Eric Maynard
wrote:
> If w
Hi Yufei,
I posted some comments in the doc.
Where do you intend to publish it?
Do we need a special process for Persistence code contributions on top of
our general contribution guidelines?
Thanks,
Dmitri.
On Tue, May 27, 2025 at 4:30 PM Yufei Gu wrote:
> Hi folks,
>
> After meeting with a
Your example is quite valid, Mike. In my proposal (several emails ago) I'd
classify this as "inputs into Polaris code".
However, I guess the topic of this thread is slightly different. The
question we're trying to reach consensus on, is about what we should
annotate as @Nullable in Polaris code.
Hi folks,
After meeting with a few folks from the community(JB, Dmitri, Keith,
Russell, etc), I put together a short guidance doc for anyone who wants to
add a new persistence back-end (think DynamoDB, Cassandra, etc.) to
Polaris. The goal is to keep our persistence layer clean and pluggable
while
I generally assume the other way around. Many (most) libraries don't
annotate the return values of their methods, so I assume everything is
nullable unless specifically told otherwise. I would prefer everything be
non-nullable unless specifically stated (the ? is the one thing I would
steal from ty
I've been doing some experimenting with storing table metadata in the
persistence, and I think I'm a fan, though I haven't yet collected real
numbers. Personally, though I think storing as separate entities is the
right approach rather than putting it in table properties. I appreciate
that we don't
Hi all
The PR polaris-tools#18 (https://github.com/apache/polaris-tools/pull/18/)
aims at adding the ability to run temporary Polaris servers using Maven and
Gradle. It is a successor to https://github.com/apache/polaris/pull/785
that was initially proposed for the apache/polaris repository.
The
On Tue, May 27, 2025 at 12:55 PM Eric Maynard
wrote:
> Could we start with it scoped to the NoSQL module and promote it out when
> another use case for it shows up?
>
>
I genuinely do not understand why a module under "tools/" is a concern.
I am open to discussing guidelines about the location o
Could we start with it scoped to the NoSQL module and promote it out when
another use case for it shows up?
On Tue, May 27, 2025 at 9:41 AM Dmitri Bourlatchkov
wrote:
> 1. If ContainerSpecHelper will be used by NoSql implementation, it should
> go to the future NoSQL module. We should make it pr
1. If ContainerSpecHelper will be used by NoSql implementation, it should
go to the future NoSQL module. We should make it private or package scope
if possible.
As one can see from the name and javadoc of that class, it is not specific
to the
upcoming NoSQL persistence, but it is planned to be us
You could add in some of the events that have been hosted recently, I know
you presented at them :)
Might also be nice to list some of the recent proposals brought to the
community just to show the amount of interest.
+1 though
On Tue, May 27, 2025 at 11:12 AM Yufei Gu wrote:
> Thanks JB for d
Hi Dmitri,
Thanks for raising this here. I have to disagree. Let me clarify my points.
1. If ContainerSpecHelper will be used by NoSql implementation, it should
go to the future NoSQL module. We should make it private or package scope
if possible.
2. The current module in the repo introduces a pub
Thanks JB for doing this.
> On Slack, since March, we have 17 new users.
Here are new users for Apache Polaris slack workspace
1. March: 53 new users
2. April: 53 new users
3. May: 28 new users so far
Yufei
On Mon, May 26, 2025 at 8:32 AM Alex Dutra
wrote:
> Hi JB,
>
> The report looks good
JB, what happened here? Is there a part of the process that is run by hand
rather than being done in a script? I can't think of what might have caused
this that went wrong with a script and we don't want future issues since
this is likely to not be caught in the future.
On Fri, May 23, 2025 at 10:
23 matches
Mail list logo
