Re: Per partition local ordering
Hi Patrick,
Really good point, I even did not think about it and actually
completely forgot that ORDER BY with DISTINCT will sort the result
within the group only, but has nothing with ordering of the final
result. I totally agree that aligning CQL with standard SQL behavior
would be a great idea. By the way, are there any open projects or
discussions around this? Or is it still just an internal PoC at this
stage?
Artem
пт, 4 апр. 2025 г. в 17:02, Patrick McFadin :
>
> I played around with this idea by simulating it in ChatGPT (Yes you can do
> that) It occurred to me that this is similar SQL functionality to the
> DISTINCT keyword. Seeing how we can align CQL with SQL is something I'm
> personally investing more time in for the long-term of the project. This
> could be an opportunity to get one step closer with useful syntax.
>
> Re-arranging your idea in SQL syntax, it would look like this:
>
> SELECT DISTINCT ON (sensor_id) device_id, sensor_id, time, value
> FROM data
> WHERE device_id = 'mydevice'
> AND sensor_id IN ('s1', 's2', 's3')
> ORDER BY sensor_id, time DESC;
>
> I think this is the same outcome and similar partition-level implementation.
> DISTINCT on a multi-partition query would return the first value of each
> partition. This would especially work in these types of primary keys: PRIMARY
> KEY((device_id, sensor_id), time)
>
> In the long term, we don't have more unique syntax building up, which I
> really prefer.
>
> Patrick
>
> On Tue, Apr 1, 2025 at 9:55 AM Artem Golovko wrote:
>>
>> Hello everyone,
>>
>> I did not find any discussions about that topic and would like to ask
>> if there any considerations to introduce the "PER PARTITION ORDER"
>> functionality. It's a duplication of Scylla question, but now for
>> Cassandra https://forum.scylladb.com/t/per-partition-local-ordering/3412.
>> I am also not so experienced from the cassandra code implementation
>> point of view, but according to my knowledge it should make sense.
>>
>> Let me introduce the use case.
>>
>> Data model:
>>
>> CREATE TABLE data(
>>device_id TEXT,
>>sensor_id TEXT,
>>time TIMESTAMP,
>>value BLOB,
>>PRIMARY KEY((device_id, sensor_id), time)
>> )
>>
>> Queries: Give me the first and the last value for all sensors within
>> deviceId.
>>
>> Problem: Within the device it's possible to have 10k of sensors or
>> more and if we wanted to get a "snapshot" (e.g. list of sensors with
>> values having the max timestamp) then it may take lots of round trips
>> for small request-response. Therefore we can use the "IN" clause here,
>> grouping keys based on the replica node (e.g. batch node aware read).
>>
>> 1. First point
>> SELECT * FROM data WHERE deviceId = 'mydevice' and sensor_id IN (‘s1’,
>> ‘s2’, ‘s3’) PER PARTITION LIMIT 1
>>
>> Here we can get the first point for each partition and don’t care
>> about “global” ordering, so the resulting rows won’t be sorted by
>> clustering key and natural order will be applied only locally within
>> each partition.
>>
>> 2. Last point
>> SELECT * FROM data WHERE deviceId = 'mydevice' and sensor_id IN (‘s1’,
>> ‘s2’, ‘s3’) ORDER BY time DESC PER PARTITION LIMIT 1
>>
>> It’s not possible to use IN and ORDER BY together with paging enabled.
>> The reason is that Cassandra applies order “localy” within each
>> partition, but also applies it “globally” across the resulting rows
>> that makes cassandra store the result in-memory to apply “global”
>> sorting. But if I don’t care about “global” ordering and only want to
>> specify ordering within each partition that introduces performance
>> overhead.
>>
>> What if to introduce "PER PARTITION ORDER" statement? In most of the
>> use cases it should not introduce much benefits, because we're limited
>> to the number of keys in the IN clause (by default 100), so the result
>> should not be big enough to do not fit into the memory, but maybe
>> someone have another use case when PER PARTITION LIMIT more than 1 or
>> payload is big enough.
OpenJDK Quality Outreach: Java 24 Is Now Available!
Greetings and welcome to the latest OpenJDK Quality Outreach update!
JDK 24 was officially released (General Availability) on March 18th during
JavaOne. You can rewatch the Java 24 launch and the J1 keynote here [1]. Be
sure to also check out the Quality Outreach section here [2]. JavaOne was
amazing, and if you couldn't attend, make sure to watch the JavaOne 2025
playlist [3] regularly as sessions are gradually being added.
With the release of JDK 24, the focus now moves to JDK 25 testing. On that
note, be sure to check out the heads-up below, with more to follow. And as
always, if you experience any issues with your project running on a JDK 25
early-access builds, please don't hesitate to reach out.
[1] https://www.youtube.com/watch?v=mk_2MIWxLI0&t=12s
[2] https://www.youtube.com/live/GwR7Gvi80Xo?si=gxdqAhVbnNV0JZGt&t=2795
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzVV1xRJkRbcM2tOgVwytJAi
# Heads-up - JDK 25: New Null Checks in Inner Class Constructors
The Java Language Specification prescribes that various use sites of inner
class constructors should include null checks of the immediately enclosing
instance and from then on assumes that the reference is non-null. However, it
does not mandate such checks of the incoming instance at the declaration site
of these constructors and so core reflection, method handles, and direct
bytecode invocation can pass null as enclosing instance, which can lead to
NullPointerExceptions down the road.
Since a null enclosing instance is outside of the JLS and the future evolution
of inner classes may lead to unexpected NPEs, Java 25 will start ensuring that
references to the immediately enclosing instance are always non-null.
Starting with JDK 25, when javac is targeting release 25 or higher, it will
emit null checks for the enclosing instances in inner class constructors.
This behavioral change will lead to new NPEs in code that uses core reflection,
method handles, or direct bytecode invocation to pass null as enclosing
instance. Such code is rare and usually found in libraries or frameworks (as
opposed to in applications). It should be changed to no longer pass a null
reference.
In case these additional checks lead to issues, their emission can be prevented
with a flag: `-XDnullCheckOuterThis=(true|false)`. This should be seen as a
temporary workaround and no guarantees are made for how long this flag will be
available.
For more details, check JDK-8351274 [4].
[4] https://bugs.openjdk.org/browse/JDK-8351274
# JDK 25
The JDK 25 early-access builds 17 are available [5] and are provided under the
GNU General Public License v2, with the Classpath Exception. The Release Notes
are available here [6].
The following JEPs have been targeted to JDK 25, so far:
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
## Changes in recent JDK 25 builds that may be of interest:
- JDK-8353118: Deprecate the use of `java.locale.useOldISOCodes` system property
- JDK-8351435: Change the default Console implementation back to the built-in
one in `java.base` module
- JDK-8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on
x86_64
- JDK-8349583: Add mechanism to disable signature schemes based on their TLS
scope
- JDK-8338675: javac shouldn't silently change .jar files on the classpath
- JDK-8319447: Improve performance of delayed task handling
- JDK-8341775: Duplicate manifest files are removed by jarsigner after signing
- JDK-8303770: Remove Baltimore root certificate expiring in May 2025
- JDK-8346948: Update CLDR to Version 47.0
- JDK-8348829: Remove ObjectMonitor perf counters
- JDK-8164714: Constructor.newInstance creates instance of inner class with
null outer class
- JDK-8352716: (tz) Update Timezone Data to 2025b
- JDK-8347946: Add API note that caller should validate/trust signers to the
getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
- JDK-8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian 12
- JDK-8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException
- JDK-8347433: Deprecate XML interchange in
java.management/javax/management/modelmbean/DescriptorSupport for removal
- JDK-8328119: Support HKDF in SunPKCS11 (Preview)
- JDK-8327378: XMLStreamReader throws EOFException instead of XMLStreamException
- JDK-8024695: new File("").exists() returns false whereas it is the current
working directory
- JDK-8351224: Deprecate com.sun.tools.attach.AttachPermission for removal
- JDK-8351310: Deprecate com.sun.jdi.JDIPermission for removal
- JDK-8348561: Add aarch64 intrinsics for ML-DSA
- JDK-8351266: JFR: -XX:StartFlightRecording:report-on-exit
- JDK-8350638: Make keyboard navigation more usable in API docs
- JDK-8350464: The flags to set the native priority for the VMThread and Java
threads need a broader range
- JDK-8349860: Make Class.isArray(), Class.isInterface() and
Class.isPrimitive() non-native
- JDK-8347335: ZGC: Use limitless m
Re: [VOTE] Release Apache Cassandra 5.0.4
+1 On Mon, Apr 7, 2025 at 7:37 AM Brandon Williams wrote: > Proposing the test build of Cassandra 5.0.4 for release. > > sha1: b81163b04b1d99036730ff233595d7bfb88611d1 > Git: https://github.com/apache/cassandra/tree/5.0.4-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1391/org/apache/cassandra/cassandra-all/5.0.4/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/5.0.4/ > > The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/5.0.4-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/5.0.4-tentative/NEWS.txt >
[VOTE] Release Apache Cassandra 5.0.4
Proposing the test build of Cassandra 5.0.4 for release. sha1: b81163b04b1d99036730ff233595d7bfb88611d1 Git: https://github.com/apache/cassandra/tree/5.0.4-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1391/org/apache/cassandra/cassandra-all/5.0.4/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/5.0.4/ The vote will be open for 72 hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1's. [1]: CHANGES.txt: https://github.com/apache/cassandra/blob/5.0.4-tentative/CHANGES.txt [2]: NEWS.txt: https://github.com/apache/cassandra/blob/5.0.4-tentative/NEWS.txt
