Skip to content

Commit 1c0f078

Browse files
authored
Create CHANGELOG.md
reduced the .html version to just 25.1 as this is the first release on github.
1 parent 14d850f commit 1c0f078

File tree

1 file changed

+219
-0
lines changed

1 file changed

+219
-0
lines changed

CHANGELOG.md

Lines changed: 219 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,219 @@
1+
## The Oracle NoSQL Database (Release 25.1.13 Community Edition) Change Log
2+
3+
Release 25.1.13 Community Edition
4+
5+
### Upgrade Requirements
6+
7+
Release 25.1 supports upgrades starting with the 22.3 release. To upgrade a store directly to the current release, the store must be running release 22.3 or later.
8+
9+
If you have a store running a 20.x, 21.x or 22.1/22.2 release, we recommend that you upgrade it to the current release by first upgrading to a 23.x or 24.x release, and then upgrading from that release to the current release. If you have a store running a 19.x or earlier release and you are an Enterprise Edition user, please contact support. If you are a Community Edition user with this issue, please post a question to the [NoSQL Database Discussions forum on Oracle Communities](https://community.oracle.com/tech/developers/categories/nosql_database_discuss).
10+
11+
For more information, see the section on [Upgrading an Existing Oracle NoSQL Database Deployment](https://www.oracle.com/pls/topic/lookup?ctx=en/database/other-databases/nosql-database/25.1&id=NSADM-GUID-A768BFD0-E205-48E3-855D-9616526DE014) in the Admin Guide.
12+
13+
### Changes in 25.1.13 Community Edition
14+
15+
### New Features
16+
17+
1. Extended the SQL dialect of Oracle NoSQL to support inner joins among tables in the same table hierarchy. Two or more tables in the same hierarchy may be joined in a query. There are no restrictions on the position of the tables within the hierarchy. Self-joins (joining a table with itself) are also allowed. However, to avoid distributed joins (i.e., joins where matching rows may be located in different shards) the following restriction applies:
18+
19+
The join predicates must include equality predicates between all the shard-key columns of the joined tables. More specifically, for any pair of joined tables, a row from one table will match with a row from the other table only if the 2 rows have the same values on their shard-key columns. This guarantees that the 2 rows will be located on the same replication node.
20+
21+
See the following for an example of this feature. To show some examples of join queries we use the following tables that model a (simple) email application:
22+
23+
create table users(uid integer, user\_info json, primary key(uid))
24+
25+
create table users.messages(msgid integer, msg\_info json, primary key(msg\_id))
26+
27+
create table users.inbox(msgid integer, primary key(msgid))
28+
29+
create table users.sent(msgid long, primary key(msgid))
30+
31+
create table users.deleted(msgid long, primary key(msgid))
32+
33+
The users table stores information for each user account. The users.messages table is a child table of users and stores each message sent/received from each user. The other 3 tables are also children of users and they model different email folders. They store a message primary key (uid and msgid) for the messages that belong to the corresponding folder. All tables share the same shard-key column, i.e., the uid column. A sample user row and an associated message row are shown below:
34+
35+
{
36+
"uid" : 2,
37+
"user\_info" : {
38+
"userName" : "mark",
39+
"emailAddr" : "mark.doe@example.com",
40+
"firstName" : "Mark",
41+
"lastName" : "Doe"
42+
"organization" : "NoSQL"
43+
}
44+
}
45+
46+
{
47+
"uid" : 2,
48+
"msgid" : 10,
49+
"msg\_info" : {
50+
"sender" : "mark",
51+
"receivers" : \[ "dave", "john", "george" \],
52+
"views" : \[ "2024-07-01", "2024-07-02", "2024-07-05" \],
53+
"size" : 20,
54+
"date" : "2024-07-01",
55+
"thread\_id" : 1
56+
}
57+
}
58+
59+
The following query selects the messages that (a) belong to users working on NoSQL, and (b) are in the inbox folder of their corresponding user. The join predicates "msg.uid = u.uid" and "msg.uid = inbox.uid" make the query satisfy the above restriction.
60+
61+
SELECT msg.uid, msg.msgid, msg.msg\_info
62+
FROM users u, users.inbox inbox, users.messages msg
63+
WHERE msg.uid = u.uid and msg.uid = inbox.uid and
64+
msg.msgid = inbox.msgid and
65+
u.user\_info.organization = "NoSQL"
66+
67+
The following query returns for each message M in the inbox folder, the number of messages that belong to the same user and the same thread as M.
68+
69+
SELECT msg1.uid, msg1.msgid, count(\*)
70+
FROM users.messages msg1, users.messages msg2, users.inbox inbox
71+
WHERE msg2.uid = msg1.uid and
72+
msg1.uid = inbox.uid and
73+
msg2.msg\_info.thread\_id = msg1.msg\_info.thread\_id and
74+
msg1.msgid != msg2.msgid
75+
GROUP BY msg1.uid, msg1.msgid
76+
77+
The following query groups the inbox messages of each user according to their view date and computes the number of messages viewed per date. Notice that in this query we have to use the "$" in the alias of the users.messages table. Without the "$", the unnesting expression in the FROM clause would be msg.content.views\[\], and msg.content would be interpreted as a table name.
78+
79+
SELECT $msg.uid, $view\_date, count(\*)
80+
FROM users.messages $msg, users.inbox $inbox, $msg.content.views\[\] as $view\_date
81+
WHERE $msg.uid = $inbox.uid and $msg.msgid = $inbox.msgid
82+
GROUP BY $msg.uid, $view\_date
83+
84+
\[KVSTORE-2193\]
85+
86+
2. Extended the SQL UPDATE statement to support updates of json fields via the json merge patch specification (described here: https://datatracker.ietf.org/doc/html/rfc7386). For example, assuming that "info" is a column of type json in a table called "Foo", the following query updates the info column of the row with id = 0. It sets the value of the "state" field inside the "address" field to "OR". It also sets the value of the "firstName" field to the value of the $name external variable. If any of the targeted fields ("address", "state", and "firstName") does not exist in info, it is inserted.
87+
88+
update Foo f
89+
json merge f.info with patch { "address" : { "state" : "OR" }, "firstName" : $name }
90+
where id = 0
91+
92+
And the following query removes the "city" field, if it exists, from the address of the row with id = 2.
93+
94+
update Foo f
95+
json merge f.info.address with patch { "city" : null }
96+
where id = 2
97+
98+
\[KVSTORE-1015\]
99+
100+
3. Add support for updating multiple records if the query predicate contains a shard key.
101+
102+
Here is an example:
103+
104+
create table users(groupId string,
105+
uid integer,
106+
name string,
107+
level integer,
108+
primary key(shard(groupId), uid))
109+
110+
insert into users values("g01", 1, "alex", 0)
111+
insert into users values("g01", 2, "jack", 0)
112+
insert into users values("g02", 1, "flex", 0)
113+
114+
update users set level = level + 1 where groupId = "g01"
115+
{"NumRowsUpdated":2}
116+
117+
select \* from users;
118+
{"groupId":"g01","uid":1,"name":"alex","level":1}
119+
{"groupId":"g01","uid":2,"name":"jack","level":1}
120+
{"groupId":"g02","uid":1,"name":"flex","level":0}
121+
122+
\[KVSTORE-2292\]
123+
124+
4. Group commit for transactions on the Master node
125+
126+
Transactions on the master node that use a SyncPolicy.SYNC can now be configured to be fsynced as a group instead of requiring each transaction to be individually fsynced. This can greatly improve performance by reducing the number of fsyncs. A transaction will be considered durable when a quorum of nodes has fsynced and acknowledged the transaction.
127+
128+
Transactions using this feature will be fsynced after either a configured number of transactions have been buffered, or a configured time interval has passed. The configurations are:
129+
130+
* ReplicationConfig.MASTER\_GROUP\_COMMIT\_INTERVAL (je.rep.masterGroupCommitInterval)
131+
* ReplicationConfig.MASTER\_MAX\_GROUP\_COMMIT (je.rep.masterMaxGroupCommit)
132+
133+
This feature is disabled by default.
134+
135+
\[KVSTORE-2502\]
136+
137+
5. DbVerify will no longer fail when run on a newly created environment
138+
139+
DbVerify fails if it cannot find the MetadataTable when run on a KV environment, since this indicates catastrophic corruption in KV. However, this is an acceptable condition when the KV environment is newly created as the MetadataTable has not been created yet, so this failure is no longer reported for newly created environments.
140+
141+
\[KVSTORE-2522\]
142+
143+
6. EnvironmentFailureException error messages now include a suggestion on how to handle the error.
144+
145+
The suggestions are:
146+
147+
* RESTART\_PROCESS - Restart the process.
148+
* REOPEN\_ENVIRONMENT - Close and reopen the environment.
149+
* HUMAN\_INTERVENTION - Close the process and wait for human intervention.
150+
151+
The suggestion can also be retrieved programatically by calling EnvironmentFailureException.getSuggestion().
152+
153+
\[KVSTORE-2279\]
154+
155+
156+
### Bug and Performance Fixes
157+
158+
1. Fixed an issue that in rare cases, an elasticity operation under network partition can temporarily result in data being hosted on two rep groups. This is a split-brain issue and can cause data loss. An indication of the issue is that the two messages like the following can be observed one after another:
159+
160+
2025-02-28 15:39:22.527 UTC INFO \[rg1-rn1\] Migration source detected failure of SourceRecord\[PARTITION-493, rg1, rg2-rn1\], target returned PENDING, removing completed record
161+
2025-02-28 15:40:32.142 UTC SEVERE \[rg1-rn1\] uncaught exception in thread
162+
java.lang.IllegalStateException: \[PARTITION-493\] shard=rg1 is associated with the same shard in both the current(seq #: 1,301) and local topologies but is associated with a different shard rg2 in the new topology(seq#: 1,302).
163+
164+
The issue may eventually recover by itself when a new topology is broadcast.
165+
166+
\[KVSTORE-2276\]\[KVSTORE-2640\]
167+
168+
2. Fixed a bug that write operations may fail in some cases in absence of elastic operation.
169+
170+
\[KVSTORE-2610\]
171+
172+
3. Fixed a bug where write operations including puts and deletions might be missed in elastic operations.
173+
174+
\[KVSTORE-2373\]
175+
176+
4. Fixed a bug where a subscription stream might fail to re-authenticate itself during streaming if the source kvstore is overloaded.
177+
178+
\[KVSTORE-2571\]
179+
180+
5. Modified the implementation of the Password store file format so it will refuse to store alias names or secret values that start or end with a space or other whitespace character. Previously these whitespace characters were trimmed from the values stored, meaning that aliases or secrets with these whitespace characters would not work correctly. Leading and trailing whitespace is still permitted for aliases and secrets stored in an Oracle Wallet.
181+
182+
\[KVSTORE-2437\]
183+
184+
6. Fixed an issue where the ping command when used as a single subcommand within runadmin would return a zero exit code regardless of ping's output. For example, if one of the shards in the kvstore does not have quorum, the following command would return zero exit code:
185+
186+
java -jar KVHOME/kvstore.jar runadmin -host <hostname> -port <portname> ping
187+
188+
Now this command will return the correct error code of 3, similar to the stand-alone ping utility command.
189+
190+
\[KVSTORE-2163\]
191+
192+
7. Modified Admin CLI commands 'topology change-repfactor', 'topology rebalance', and 'topology redistribute' to check if newly added SN storage directory sizes are smaller than existing in-use sizes. In this case, the topology will not be able to use new SNs. The topology commands now include information about the issue to alert users.
193+
194+
A sample warning message:
195+
196+
Note: Some new SN storage directory sizes are smaller than the smallest
197+
existing storage directory size, which may prevent new SNs from being
198+
used in the new topology. The smallest existing SN storage directory
199+
size is 2147483648, but the following smaller new SN storage directory
200+
sizes were specified: {sn4={/usr/kvroot4=1073741824},
201+
sn5={/usr/kvroot5=1073741824}}
202+
203+
\[KVSTORE-2036\]
204+
205+
8. When setting a storage directory size parameter on an SN, the system now verifies that the specified sizes for all storage directories on the same device do not sum to a size exceeding the total storage size of the device. Before the fix, makebootconfig and 'plan change-storagedir' checked the size of each storage directory, but not the sum of all directories on the same device.
206+
207+
\[KVSTORE-1684\]
208+
209+
9. Fixed a problem that could cause the JVM to fail when starting a replica node process because of unsupported JVM arguments. The fix is to identify known obsolete arguments for a specific Java version and exclude them before the process is started.
210+
211+
\[KVSTORE-2509\]
212+
213+
10. Fixed an issue in Admin CLI pool create command so that it is no longer possible to use the empty string or a string of blank spaces when specifying a pool name or zone name. The system now returns a warning instead.
214+
215+
\[KVSTORE-1694\]
216+
217+
### Deprecations
218+
219+
None

0 commit comments

Comments
 (0)