YottaDB r1.34 released

36 views
Skip to first unread message

K.S. Bhaskar

unread,
Feb 25, 2022, 3:35:33 PM2/25/22
to hard...@googlegroups.com, comp.la...@googlegroups.com, enterprise-web-de...@googlegroups.com, K.S. Bhaskar
While YottaDB r1.34 is an otherwise modest successor to r1.32, internal changes allow the popular programming language Python to be fully Supported. We are excited about making YottaDB available to the large Python user community. Here is a “Hello, World” Python program that updates the database and illustrates YottaDB’s Unicode support:

import yottadb

if __name__ == "__main__":
yottadb.set("^hello", ("Python",), value="नमस्ते दुनिया")

The Python wrapper can be installed with pip install yottadb. Full details of the API are in the Python wrapper user documentation (https://docs.yottadb.com/MultiLangProgGuide/pythonprogram.html). The current Debian Docker image at Docker Hub (https://hub.docker.com/r/yottadb/yottadb-debian) includes the Python wrapper. We thank Peter Goss for his contributions to the Python wrapper.

Python joins C, Go, M, node.js, Perl, and Rust as languages with APIs to access YottaDB.

Owing to an internal change required to support the Python wrapper, application code written in Go and Rust will need to be compiled with new versions of the Go and Rust wrappers. We anticipate no regressions, and apologize for the inconvenience. (The new Rust wrapper is available now; the new Go wrapper will be released next week.)

As promised in recent blog post on Fuzz Testing YottaDB (https://yottadb.com/fuzz-testing-yottadb/), we accelerated the release of YottaDB r1.34 to release fixes to the first tranche of bugs found by fuzz testing. We thank Zachary Minneker of Security Innovation (https://www.securityinnovation.com/) for Fuzz Testing YottaDB and bringing its benefits to our attention.

In addition to fixes for issues, whether found by fuzz testing or otherwise, YottaDB r1.34 has enhancements that make it faster and more friendly, e.g.,

  • Faster stringpool garbage collection, thanks to Alexander Sergeev and Konstantin Aristov.
  • HOME and END keys work in direct mode for READ, thanks to Sergey Kamenev.
  • Multiple improvements to ydbinstall / ydbinstall.sh.
  • Enhancements to ydb_env_set to improve performance under some conditions and to be compatible with existing environments created without ydb_env_set.
  • Enhancements to the %RSEL utility program.

YottaDB r1.34 also inherits enhancements and fixes from GT.M V6.3-011.

Details are in the release notes (https://gitlab.com/YottaDB/DB/YDB/-/releases/r1.34).

Please try YottaDB r1.34 and let us know what you think. Thank you for using YottDB.

Regards
– Bhaskar

--
YottaDB - Rock solid. Lightning fast. Secure. Pick any three.

Raman Sailopal

unread,
Feb 25, 2022, 3:53:14 PM2/25/22
to enterprise-web-de...@googlegroups.com, hard...@googlegroups.com, comp.la...@googlegroups.com, K.S. Bhaskar
Great to see YottaDB continually develop more and more!!

A quick question about the built in Python binding. Does it allow remote client connections to the database?

Ram

--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enterprise-web-develope...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/enterprise-web-developer-community/CAH%2BrS9cCnGT5d5HLSSh78z_jfWywJjFv%2BgY61b_N9D4EYW4Hzw%40mail.gmail.com.

K.S. Bhaskar

unread,
Feb 25, 2022, 4:09:01 PM2/25/22
to Enterprise Web Developer Community
Thanks Ram. This is an in-process API to the database, not a remote connection. However, YottaDB does have the concept of a database region on a remote server. So, you can run YottaDB locally with one or more database regions served by a remote server (see https://docs.yottadb.com/AdminOpsGuide/gtcm.html).

Regards
– Bhaskar

Rob Tweed

unread,
Feb 26, 2022, 3:18:00 AM2/26/22
to enterprise-web-de...@googlegroups.com
So here’s an idea: Python supports dictionaries, which are essentially in-memory associative arrays. It also supports JSON these days. Both directly map to and from M‘s hierarchical global storage, as I’ve extensively written about with respect to Javascript/Node.js. My QEWD-jsdb concept takes the idea further to create what I often called “the Javascript equivalent of the M up-arrow”, whereby you have apparently seamless on-disc JSON/Javascript objects, just like M has local and persistent data storage, the only difference of which to a developer is the presence or absence of the leading up-arrow.

Now, I’m not a Pythonista, so I’m not the person for the job, but I’d be more than happy for someone who is up to the job to take my QEWD-jsdb logic (all available as open source on GitHub) and create a Python equivalent. There doesn’t seem to be any reason, in my mind, why it shouldn’t be possible: persistent Python JSON and dictionaries… Sounds like a win to me.

Any takers? Thoughts?

Rob

Sent from my iPhone

On 25 Feb 2022, at 20:35, K.S. Bhaskar <ksbh...@gmail.com> wrote:


--

K.S. Bhaskar

unread,
Feb 26, 2022, 11:07:22 AM2/26/22
to Enterprise Web Developer Community
Rob –

Creating a Pythonic equivalent of M's caret would certainly benefit Python applications. So, I hope you find some takers.

Regards
– Bhaskar

winfrie...@e-ntwicklung.de

unread,
Feb 27, 2022, 2:39:38 AM2/27/22
to enterprise-web-de...@googlegroups.com
Something like in my C++-Wrapper…???


/*
Attention, kills and modifies globals ^g and ^counter
Error handling via method last_error()
*/
#include <iostream>
#include <string>
#include "ydb-global.h"
using namespace std;
int main() {
c_ydb_global _g("^g"), _counter("^counter");
int a;
string v = "Hello world";
cout << "counter: " << --_counter << endl;
cout << "counter: " << (_counter += 2) << endl;
_g.kill();
_g[4][8] = "g_4_8";
_g = 4712;
_g["4"][8] = "g_4_8 2";
_g["2"]["3"] = 222;
_g[3] = 333;
_g["A99"] = "This is A99";
_g["A100"] = v;
_g["A2"] = v + " - " + v;
_g[7] = 777;
v = _g["A99"];
a = +_g[7];
cout << a << " " << _g << endl;
indexList l = indexList{"2"};
cout << _g(l)[3] << endl;
return 0;
}

Raman Sailopal

unread,
Mar 1, 2022, 4:15:00 AM3/1/22
to enterprise-web-de...@googlegroups.com
Definitely sounds like an idea. 

I'd definitely be interested..

Reply all
Reply to author
Forward
0 new messages