Re: [PR] AVRO-4037: [C++] Add local-timestamp-millis, local-timestamp-micros logical types [avro]

2024-08-19 Thread via GitHub


martin-g merged PR #3053:
URL: https://github.com/apache/avro/pull/3053


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Preparing for release 1.11.4 [avro]

2024-08-19 Thread via GitHub


Fokko merged PR #3101:
URL: https://github.com/apache/avro/pull/3101


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Status of AVRO-2078 - enforcement of Avro schema resolution rules for Decimal type? (java)

2024-08-19 Thread Katrin Skoglund
Hey folks,

I’m wondering about this old Jira and PR from 2017 
(https://issues.apache.org/jira/browse/AVRO-2078). It’s a bit scary to work 
with decimal types in Avro from Java since changes in precision and scale are 
not considered incompatible but will royally mess up the data if introduced. We 
have implemented our own validation for this and I was considering adding that 
as a PR when I found this one.

The Avro spec says “For the purposes of schema resolution, two schemas that are 
decimal logical types match if their scales and precisions match”, so that’s 
pretty clear IMO.

My question is basically:
Is there a chance of getting this validation merged? If not as-is, then maybe 
modified in some way (like making logical types validation configurable).

I’m happy to help with the PR or create a new one if needed.

Best,
Katrin


Re: Status of AVRO-2078 - enforcement of Avro schema resolution rules for Decimal type? (java)

2024-08-19 Thread Martin Grigorov
Hi,

On Mon, Aug 19, 2024 at 2:51 PM Katrin Skoglund
 wrote:

> Hey folks,
>
> I’m wondering about this old Jira and PR from 2017 (
> https://issues.apache.org/jira/browse/AVRO-2078). It’s a bit scary to
> work with decimal types in Avro from Java since changes in precision and
> scale are not considered incompatible but will royally mess up the data if
> introduced. We have implemented our own validation for this and I was
> considering adding that as a PR when I found this one.
>
> The Avro spec says “For the purposes of schema resolution, two schemas
> that are decimal logical types match if their scales and precisions match”,
> so that’s pretty clear IMO.
>
> My question is basically:
> Is there a chance of getting this validation merged? If not as-is, then
> maybe modified in some way (like making logical types validation
> configurable).
>

I am not very familiar with the Java SDK, so I cannot comment on the
technical solution but the PR has 5 files with merge conflicts, so it
cannot be merged "as-is" for sure.
Someone will have to rebase it to main branch!

Martin



>
> I’m happy to help with the PR or create a new one if needed.
>
> Best,
> Katrin
>


Re: Status of AVRO-2078 - enforcement of Avro schema resolution rules for Decimal type? (java)

2024-08-19 Thread Katrin Skoglund
I'm more than happy to fix the merge conflicts in a new PR (unless the original 
PR author can pick it up and do it), but I want to check first if there is a 
chance that it can be merged at all. The last comment in the Jira says as 
follows:

--- quote ---
nandorKollar commented on issue #247: AVRO-2078: Avro does not enforce schema 
resolution rules for Decimal …
URL: https://github.com/apache/avro/pull/247#issuecomment-398326638
Hey @big-andy-coates ! I didn't yet merge this PR, because the logical type 
schema resolution rules are not well defined, and there was some debate how we 
should handle it. The spec mentions an evolution rule for Decimal, but other 
types are not mentioned at all, therefore no evolution rule is defined for 
example Time -> Timestamp promotion. Is it allowed? How should Avro interpret 
the value? Right now if one uses generated classes, the methods will return 
wrong values, because the in memory representation is incorrect!
The current implementation doesn't conform with the specification, because it 
omits changes in the decimal parameters, but I'm not sure if we should change 
the spec, or get this PR merged. I found a discussion on AVRO-1721 (actually 
you're the last one who commented it), which is about similar topic, and looks 
like there was no consensus about the correct approach. Could you please open 
this topic for discussion on the dev list?
--- end quote ---

IMO there is no need to increase the scope like this. The questions regarding 
other logical types are not problematic in practice since any changes in those 
will break compilation in Java. Moreover, they are not mentioned in the spec. 
The problem with Decimal is that it will have the same representation in Java 
(BigDecimal), so everything will keep working, only the data will be wrong.

//Katrin



On 2024-08-19, 13:56, "Martin Grigorov" mailto:mgrigo...@apache.org>> wrote:


EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust 
the sender and know the content is safe.


Hi,


On Mon, Aug 19, 2024 at 2:51 PM Katrin Skoglund
mailto:katrin.skogl...@avanza.se.inva>lid> 
wrote:


> Hey folks,
>
> I’m wondering about this old Jira and PR from 2017 (
> https://issues.apache.org/jira/browse/AVRO-2078 
> ). It’s a bit scary to
> work with decimal types in Avro from Java since changes in precision and
> scale are not considered incompatible but will royally mess up the data if
> introduced. We have implemented our own validation for this and I was
> considering adding that as a PR when I found this one.
>
> The Avro spec says “For the purposes of schema resolution, two schemas
> that are decimal logical types match if their scales and precisions match”,
> so that’s pretty clear IMO.
>
> My question is basically:
> Is there a chance of getting this validation merged? If not as-is, then
> maybe modified in some way (like making logical types validation
> configurable).
>


I am not very familiar with the Java SDK, so I cannot comment on the
technical solution but the PR has 5 files with merge conflicts, so it
cannot be merged "as-is" for sure.
Someone will have to rebase it to main branch!


Martin






>
> I’m happy to help with the PR or create a new one if needed.
>
> Best,
> Katrin
>





[PR] Bump syn from 2.0.74 to 2.0.75 in /lang/rust [avro]

2024-08-19 Thread via GitHub


dependabot[bot] opened a new pull request, #3107:
URL: https://github.com/apache/avro/pull/3107

   Bumps [syn](https://github.com/dtolnay/syn) from 2.0.74 to 2.0.75.
   
   Release notes
   Sourced from https://github.com/dtolnay/syn/releases";>syn's 
releases.
   
   2.0.75
   
   Automatically fill in missing turbofish when printing ExprPath and other 
paths in expression position (https://redirect.github.com/dtolnay/syn/issues/1722";>#1722)
   
   
   
   
   Commits
   
   https://github.com/dtolnay/syn/commit/d1746fe29d18ca704ed285844c365a14a77e8757";>d1746fe
 Release 2.0.75
   https://github.com/dtolnay/syn/commit/b6936825a637376dd7584653e13776034759d3fd";>b693682
 Merge pull request https://redirect.github.com/dtolnay/syn/issues/1722";>#1722 from 
dtolnay/exprpath
   https://github.com/dtolnay/syn/commit/e459ee75bb60f54ce3ca1fb42f515936c06582a4";>e459ee7
 Insert turbofish into paths in expression position
   https://github.com/dtolnay/syn/commit/3bb65aaae153130c3053bc691080aad9eb60a55c";>3bb65aa
 Add mod-style printing for paths that cannot contain generic args
   https://github.com/dtolnay/syn/commit/ae8c84ab744b8c95d6b2607d3987590c12ef5280";>ae8c84a
 Handwrite ToTokens impl for Meta
   https://github.com/dtolnay/syn/commit/5dbfeae027d3d5356289bbd37f5daede30a838cc";>5dbfeae
 Name the expr_style argument at all call sites of path::parsing::qpath
   See full diff in https://github.com/dtolnay/syn/compare/2.0.74...2.0.75";>compare 
view
   
   
   
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=syn&package-manager=cargo&previous-version=2.0.74&new-version=2.0.75)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   
   Dependabot commands and options
   
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot merge` will merge this PR after your CI passes on it
   - `@dependabot squash and merge` will squash and merge this PR after your CI 
passes on it
   - `@dependabot cancel merge` will cancel a previously requested merge and 
block automerging
   - `@dependabot reopen` will reopen this PR if it is closed
   - `@dependabot close` will close this PR and stop Dependabot recreating it. 
You can achieve the same result by closing it manually
   - `@dependabot show  ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Bump syn from 2.0.74 to 2.0.75 in /lang/rust [avro]

2024-08-19 Thread via GitHub


martin-g merged PR #3107:
URL: https://github.com/apache/avro/pull/3107


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] Build website through Github Actions [avro]

2024-08-19 Thread via GitHub


Fokko merged PR #3092:
URL: https://github.com/apache/avro/pull/3092


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@avro.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[VOTE] Apache Avro 1.11.4 RC1

2024-08-19 Thread Fokko Driesprong
Hi everyone,

I'd like to propose the following RC1 to be released as the official Apache
Avro 1.11.4 release.

The commit ID is 6f119ef077e3a50382ba13164afecdf84408fc2f
* This corresponds to the tag: release-1.11.4-rc1
* https://github.com/apache/avro/releases/tag/release-1.11.4-rc1

The release tarball, signature, and checksums are here (revision r64034)
* https://dist.apache.org/repos/dist/dev/avro/avro-1.11.4-rc1/

You can find the KEYS file here:
* https://dist.apache.org/repos/dist/release/avro/KEYS

Binary artifacts for Java are staged in Nexus here:
* https://repository.apache.org/content/repositories/orgapacheavro-1038/

This release includes ~63 Jira issues:
* https://issues.apache.org/jira/projects/AVRO/versions/12353655

The easiest way to test the release is using Docker:

wget -q
https://dist.apache.org/repos/dist/dev/avro/avro-1.11.4-rc1/avro-src-1.11.4.tar.gz
tar -xvzf avro-src-1.11.4.tar.gz
cd avro-src-1.11.4
./build.sh docker-test

Please download, verify, and test. This vote will remain open for at least
72 hours.

[ ] +1 Release this as Apache Avro 1.12.0
[ ] 0
[ ] -1 Do not release this because...

Kind regards,
Fokko