Re: [DISCUSS] Evaluate usage of Immutables library

For JSON serialization of objects such as FileScanTask, I have been experimenting about the best way to achieve that. So far the best way I see is actually still to use a fully customized JSON parser like what we did for TableMetadata. This is because there are many sub-classes of the FileScanTask

[GitHub] [iceberg-docs] jackye1995 commented on pull request #1: First version of hugo doc site

jackye1995 commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989324679 yes, `next` is really good-to-have stuff, I saw it in a few other Apache websites that's why I brought it up, but if it's too much effort for community to maintain then we can

[GitHub] [iceberg-docs] rdblue commented on pull request #1: First version of hugo doc site

rdblue commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989323751 Yeah, that sounds reasonable to me. I still question whether we even want to have `next`. In any case, there's still a lot of work to do here to make sure we have everything the w

[GitHub] [iceberg-docs] jackye1995 commented on pull request #1: First version of hugo doc site

jackye1995 commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989319785 > I'd focus on getting just 0.12.1 done. We can add more versions later Yeah I was just gonna ask about that, I thought we are going to first create those doc branches f

[GitHub] [iceberg-docs] rdblue commented on pull request #1: First version of hugo doc site

rdblue commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989311369 For the conversation about a `next` branch: * I don't see much value in having docs for the upcoming release. Maybe it's just me, but I'd not prioritize this very highly. * I

[GitHub] [iceberg-docs] rdblue commented on pull request #1: First version of hugo doc site

rdblue commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989309666 It looks like this isn't quite ready to merge. Most of the text links on pages are broken and the nav menu is really huge. Nav links go to paths like `/spark-ddl/` but I think we

[GitHub] [iceberg-docs] rdblue commented on a change in pull request #1: First version of hugo doc site

rdblue commented on a change in pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#discussion_r765318518 ## File path: content/docs/_index.md ## @@ -0,0 +1,54 @@ +--- +title: Introduction +type: docs +--- + + + + +**Apache Ice

[GitHub] [iceberg-docs] rdblue commented on a change in pull request #1: First version of hugo doc site

rdblue commented on a change in pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#discussion_r765318054 ## File path: config.toml ## @@ -0,0 +1,24 @@ +baseURL = "" # This is populated by the github deploy workflow and is equal to "/" +languageCode = "en-us"

[GitHub] [iceberg-docs] rdblue commented on a change in pull request #1: First version of hugo doc site

rdblue commented on a change in pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#discussion_r765314353 ## File path: config.toml ## @@ -0,0 +1,24 @@ +baseURL = "" # This is populated by the github deploy workflow and is equal to "/" +languageCode = "en-us"

Re: [DISCUSS] Evaluate usage of Immutables library

This could be valuable for some things, but I'm skeptical that we would want to rewrite significant pieces of existing code this way. For example, you mentioned being able to "get rid of hand-written JSON serializers/deserializers". Automatic serialization is fiddly. You end up needing to scatter

[GitHub] [iceberg-docs] samredai commented on pull request #1: First version of hugo doc site

samredai commented on pull request #1: URL: https://github.com/apache/iceberg-docs/pull/1#issuecomment-989259177 > How are we going to move forward with this PR? If we move to the `next` branch, is this PR for the `main` branch still needed? If a `next` branch is created I can re-ope

[DISCUSS] December board report

Hi everyone, It’s time for another board report from Iceberg. I’ve gone ahead and prepared a draft. If you have anything to add, please reply with updates. Ryan Description: Apache Iceberg is a table format for huge analytic datasets that is designed for high performance and ease of use. Issues:

Re: Vendor integration strategy

The main problem with creating runtime Jars is transitive dependencies. Getting a minimal set of transitive dependencies, relocating the classes that they pull in to avoid conflicts, and tracking licensing is a huge amount of work that has so far been done or validated by a very small set of people

[DISCUSS] Evaluate usage of Immutables library

Hello everyone, I was curious what people think about introducing/using the Immutables library in Iceberg. The Immutables library (Apache License 2.0) works via annotation processing, where an abstract value class is annotated with *@Value.Immutable* to generate an