Introducing IRIS DocDB Explorer: A Sleek UI for Managing JSON Documents in InterSystems IRIS

IRIS offers a dedicated feature for storing and retrieving JSON documents using DocDB, without requiring a predefined schema.

Hi everyone,

It's me again😁. As usual I would like to share something I study recently, and today, I would like to share about the document DB😁.

1st of all, let's go to the documentation https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GDOCDB_intro
Well, I must say, this one is much better to follow than the others, which I read before. 😭 Finally😭😭

Ok, let's start walking through it together

Here we go😀, we start a terminal from VSCode to connect to our IRIS

We are going to created Document DB demo.docpatient
 

1.1 Check the Document DB exist or not

Plotting the gnSSLocation data from my Rivian R1S across Michigan with InterSystems Cloud Document and Databricks

InterSystems IRIS Document Database (DocDB) offers a flexible and dynamic approach to managing database data. DocDB embraces the power of JSON (JavaScript Object Notation), providing a schema-less environment for storing and retrieving data.

It is a powerful tool, enables developers to bypass a ton of boiler plate code in interaction with existing applications, serialization, pagination and integration. the seamless flow of DocDB with Interoperability Rest services and operations, gives a big leap in API production and management.

Hello all,

Using the example from the DocDB documentation below, is there a way to create a property and form a predicate that would be able to find a document where the phone number is a cell number and the number is "401-123-4567"?

From Introducing InterSystems IRIS Document Database (DocDB)

Before we start talking about databases and different data models that exist, first we'd better talk about what a database is and how to use it.

A database is an organized collection of data stored and accessed electronically. It is used to store and retrieve structured, semi-structured, or raw data which is often related to a theme or activity.

At the heart of every database lies at least one model used to describe its data. And depending on the model it is based on, a database may have slightly different characteristics and store different types of data.

Hello all,

I'm "playing" a little bit with IRIS as document database, as it seems really simple to use.

So far, creating a database and inserting documents is fine. Creating a Property so it can be indexed seems very useful and it works well when this property is created at the very beginning. But here my "problem": whenever a new property is added, how can the values be recalculated and inserted, so indices can be correctly updated? 

So far, I've only found as a solution opening and saving the documents :'( This is ok for a POC, but what when millions of documents are stored?

hello, I had build a DocDB referring the code from here: https://community.intersystems.com/post/how-can-i-create-properties-doc…

Here are the structure of the json Documents I have added in my database called 'Orders'.

For the benefit of those who want to use the Document Database (DocDB) capabilities within InterSystems IRIS, and specifically the REST API it provides, I put together a PostmanCollection that provides samples for several basic calls.

For example:

I have an application with maps that render and edit geographic data in a some layers using KML - geo data represented into XML file with layers, polygnons, points and metadata associated with it. Some maps are in GeoJSON too. 

Is it DocDB the better option?

Hello everyone,

i want to create an iris document database with Atelier with some properties, where i can import my JSON formatted data from an API to the database which i created. Right now i know how to import my local JSON formatted data to my created database:

ClassUser.Classtest

{

ClassMethodgetFile()as%Status

{

               setfilename="/home/student/Downloads/own_scrobble.json"

               IF$SYSTEM.DocDB.Exists("db.Streamingdatabase"){

                              SETdb=##class(%DocDB.Database).%GetDatabase("db.Streamingdatabase")

                              }

Hello,

I have imported my data with the following code (%DocDB).

set filename = "/home/student/Dokumente/convertcsv.json"

IF $SYSTEM.DocDB.Exists("Fitabase1") { 

SET db = ##class(%DocDB.Database).%GetDatabase("Fitabase1")

}

ELSE {

SET db = ##class(%DocDB.Database).%CreateDatabase("Fitabase1") 

}

set arr = ##class(%DynamicAbstractObject).%FromJSON(filename)

SET jstring = arr.%ToJSON()

//SET doccount = db.%Size()

DO db.%FromJSON(jstring) 

Now I have data sets like 

MonCaché — MongoDB API implementation based on InterSystems Caché

Disclaimer: This article reflects author's private opinion and has no relation to the official position of InterSystems.

IDEA

The idea of the project is to implement basic MongoDB (v2.4.9) API features for searching, saving, updating and deleting documents in a way that will allow the use of InterSystems Caché instead of MongoDB without changing the code on the client side.

MOTIVATION

See 

http://www.datasciencecentral.com/profiles/blogs/ten-top-nosql-databases

What will it take before Cache begins to appear on (or at the very least be considered for) such lists?

Does anybody know how can I get the DocumentId property from a DocDM repository using SQL?. So far my SQL is like this:

SELECT name,email,gender FROM JSON_TABLE(
  'person',
  '$' COLUMNS(
    name VARCHAR(100) PATH '$.name',
    email VARCHAR(100) PATH '$.email',
    gender VARCHAR(2) PATH '$.gender'
  )
) 

Thanks!

Introduction

The field test of Caché 2016.2 has been available for quite some time and I would like to focus on one of the substantial features that is new in this version: the document data model. This model is a natural addition to the multiple ways we support for handling data including Objects, Tables and Multidimensional arrays. It makes the platform more flexible and suitable for even more use cases.

I was trying to modify the REST.DocServer sample in the SAMPLE namespaces to use the new %Object and %Array system objects (Ensemble 2016.2 build 636) with the following changes:

/// This method returns a list of namespaces for this server

ClassMethod GetNamespaces() As %Status

{

    #dim tSC As %Status = $$$OK

    #dim tList,tNS,tFilteredList,tValue As %String

    #; Get the list of namespaces

    Do List^%SYS.NAMESPACE(.tList)

    Set tNS="" For  {

        Set tNS=$Order(tList(tNS),1,tValue) If tNS="" Quit

        #; Only want namespaces which are enabled and are not remote

Presenter: Stefan Wittmann
Task: Take advantage of the NoSQL paradigm without adding another tool
Approach: Provide sample use cases that are an excellent fit for InterSystems’ new document data model
 

Description: Designing applications always requires you to make assumptions about your data model. Come to this session to learn how you can effectively handle the cases where you have to rapidly evolve your model. We will also discuss other use cases that are an awesome fit for the flexible document data model.

I am pleased to announce the next 2016.2 field test kit, 2016.2.0.605.0.

There are about a hundred changes from the previous field test kit, including the following fixes to problems found by those using the kits in the field:

• DLP3516, which fixes a problem in the Demo.Document.Data.Loader class
• RJW2416, which fixes a problem with the telnet client disconnecting on Windows

I am pleased to announce the next 2016.2 field test kit, 2016.2.0.595.0.

It may look like a slow week, with less than fifty changes having been checked in, but this kit includes the following fixes to problems found by you, the ones running the kits in the field:

• ALE2845, which fixes the cachejdbc.jar version
• JN1637, which fixes an issue that blocked debugging Atelier when used in conjunction with Kerberos
• DLP3508, which fixes a JSON issue with $compose()

The rest of the fixes have been spread among different areas of the product, chief among them DOCUMENT Data Model, SQL and Atelier.