DEV Community: Hartmut B.

ArcadeDB, Ruby && Jupyter

Hartmut B. — Fri, 19 Jan 2024 07:08:31 +0000

Jupyter Notebooks are widely used in data science, scientific computing, and machine learning due to their interactive nature and ability to present code, results, and explanations in a clear and organized manner. The IRuby Project introduces a modern ruby kernel to jupyter and opens the environment for ruby projects.

The ArcadeDB Ruby Interface naively supports iruby jupyter notebooks.

To activate include both gems in the Gemfile

## Gemfile
gem 'arcadedb'
gem 'iruby'

Jupyter-output is realized through IRuby.display, IRuby.html and IRuby.table-commands in the to_html-method of the class to be supported. ArcadeDB-database objects inherit this to_html-implementation

def to_html  # iruby
  the_rid = "[#{rid}] : {#{self.in.count}->}{->#{self.out.count }}"
  IRuby.display IRuby.html "<b>#{self.class}</b>#{the_rid} < #{html_attributes.map{|_,v|  v }.join(', ')} >"
end

which leads to the following output

Member.find name: ‘Gross’
Member[#49:43] : {0->}{->0} < Frau, Maria, Gross, Lüneburg, Hauptstr. 12a >

Customization

The default output is defined by

def html_attributes  # Standard
  invariant_attributes
end

It includes all properties except created_at and modified_at. Customization is straightforward:

def html_attributes  # model/arcade/member.rb
 {     Sex: :sex,
   Vorname: :surname,
      Name: :name,
       Ort: :town,
    Straße: :street } 
end

This affects the output of tables, too.
Member.where returns an array and triggers the expected jupyter-output:

Member.where name: ‘Gross’

Sex Vorname Name Ort Straße

Frau Maria Gross Lüneburg Hauptstr. 12a

Advanced Visualization && Calculations

The ecosystem of applications supporting jupyter notebooks is slowly growing. Visualizations of any kind are realized with the excellent vega gem. Jupyter notebooks are supported.

ArcadeDB database contents are easily exported to polars dataframes.

A typical workflow would be to use

arcadedb to store and easily retrieve the data,
export them to polars dataframes, perform extensive calculations and use
vega for visualization.

The ruby script runs in a python environment, uses a java-based database for storage, a rust-powered Dataframe-Engine for calculations and a javascript library to present the results.

To experiment with this environment in jupyter, the Github respiratory from the Ruby Adventures with ArcadeDB Series contains an iruby directory.
Clone it, install Jupyter and ìruby, go to theiruby-directory and enterjuypter notebook` to start Jupyter in the standard browser. Enjoy!

Ruby Adventures with ArcadeDB 2

Hartmut B. — Mon, 11 Dec 2023 17:27:20 +0000

note: Clone the git respiratory https://github.com/topofocus/dev-adventures to play with the data. :end-note

Part One: Ruby Adventures with ArcadeDB

Some Basics

ActiveRecord is the standard abstraction layer for databases in ruby. It translates ruby code to SQL, optimizes queries and is compatible to many low level database drivers. Its promise: You don't have to know anything about databases, can use every relational database – everywhere. Just stick to ruby code.

Relational databases are a popular way to organize structured data. But data sets aren't always neatly organized. Sometimes, the data is forced into a mold that doesn't fit just because the tool requires it.

ArcadeDB is a modern multi model database. Its promise is analogous to ActiveRecord: Whatever the structure of your data is, the database offers an effective host. The ruby-interface to ArcadeDB aims to combine the
user friendlines of ActiveRecord and the flexibility of ArcadeDB.

The Power of RID

Relational Databases organize data in tables. Very often, a column is called id and carries the index. ArcadeDB too has tables. They're called types and carry object-oriented behaviors. In addition the local data-structure can always inspected via RID's.
This is happening:

select from #1:0

{:@rid=>"#449:0", :@type=>"human", :@cat=>"v", :name=>"hugo }

The RID exposes itself as human-type, its a vertex (@cat: "v") and has a property name.

The ruby-interface connects the @type to an appropriate Model class, assigns the database properties to corresponding model-attributes and exposes the data to customized model-methods.

Its much simpler to access pieces of data from ArcadeDB then from any relational database. ArcadeDB is a native object database, no abstraction is needed to fit the data representation in the database to the data-model in your ruby program.

Exploring the Structure

The Account-Type is a vertex. This implies, it might have edges, that connect it to other vertices. This is explored with the nodes-method

> first_human =  DB.get 1,0      # select from #1:0
> [<human[#1:0]:{0->}{->1}, name: hugo>] 
> first_account.nodes              # select both() from #1:0
> [<human[#2:0]:{1->}{->0}, name: berta>]

A connected Account-record is retrieved!

Bidirectional connections – with attributes

Lets design a simple relation

> first_account.assign via: IsMarriedTo
                        to: second_account
                      date: Date.new( 1955, 12, 21)
                      town: "Dublin"

If -- by convention -- outgoing connections belong to the male and incoming one to the female, a query of Human's which got out-connections of type IsMarriedTo, loads a list of married man. Compare that to efforts needed with relational databases.

Its possible to use the node-method here, too.
But ArcadeDB offers a versatile alternative.

Arcade::Match.new( type: Human, as: :h)
             .out( IsMarriedTo )
             .execute { "h.rid, h.name" }

Arcade::Match is a simple wrapper of the Match Statement, which »queries the database in a declarative manner, using pattern matching (inspired by Cypher)«.
The compiled match statement looks like this:

MATCH { type: human, as: h }
      .out( 'is_married_to')
RETURN h.rid, h.name

and returns an array with all rid's and names of the suspects.

The query is easily extended to only marriages in the last decade of the 20th century:

Arcade::Match.new( type: Human, as: :h)
             .out( IsMarriedTo , where: { date: 1990 .. 2000})
             .execute { "h.rid, h.name" }
=> MATCH { type: human, as: h }
      .out( 'is_married_to', where: ( date between 1990 and 2000) )
RETURN h.rid, h.name

The properties on the bidirectional connection(edge) are essential to this query.

ArcadeDB is not only a object-database regarding to the data-storage but to the connections between the data itself.
If a couple divorces, the IsMarriedToconnection is replaced by a IsDivorced-edge. Both edge-classes are childs of IsFriend Edges.

Until now, this example lacks realism, as same-sex marriages are not allowed (Only man have out-connections). This can easily be addressed via inheritance.

The final setup of the database looks as following

DB = Arcade::Init.db  # Reference to the database
[Male, Female, IsMarriedTo, IsDivorced].each { |y| y.create_type  }  
# Inheritance is respected, `Human` and `IsFriend` are allocated implicitly

hugo, paul, jochen = ['Hugo', 'Paul', 'Jochen'].map do | man |
   Male.insert name: man
end
berta, hilde, maria = ['Berta', 'Hilde', 'Maria'].map do | woman |
   Female.insert name: woman
end
hugo.assign via: IsMarriedTo, town: 'Duesseldorf', date: Date.new(1956,12,1), to: berta
paul.assign via: IsDivorced, date: Date.new(1959,4,5), to: hilde
maria.assign via: IsFriend, to: [ jochen, hilde, hugo ]

Verify the data structure

Human.all
=> [<male[#66:0]:{1->}{->1}, name: Hugo>,                 
    <male[#69:0]:{0->}{->1}, name: Paul>,                 
    <male[#72:0]:{1->}{->0}, name: Jochen>,
  <female[#90:0]:{1->}{->0}, name: Berta>,
  <female[#93:0]:{2->}{->0}, name: Hilde>,
  <female[#96:0]:{0->}{->3}, name: Maria>]

Female.find( name: 'Maria').out
=>                                                                 
[  <male[#66:0]:{1->}{->1}, name: Hugo>,                              
 <female[#93:0]:{2->}{->0}, name: Hilde>,                           
   <male[#72:0]:{1->}{->0}, name: Jochen>]

# query for divorced couples
Arcade::Match.new( type: Human, as: m)
             .out(IsDivorced)
             .node( as: :f)
             .execute { "m.name, f.name" }

INFO->Q: MATCH { type: human, as: m }
                .out('is_divorced')
               { as: f } 
         RETURN m.name, f.name 
 =>                                                                                                          
[{:m.name =>"Paul", :f.name=>"Hilde"}]

( to be continued ... )

Ruby Adventures with ArcadeDB

Hartmut B. — Wed, 25 Oct 2023 14:39:01 +0000

ArcadeDB is a modern, multi purpose Not-Only-SQL database. The ArcadeDB-Gem opens the database for ruby-projects.

The database is organized with types. A database-type is either a document, a vertex or an edge.

Similar to other database-adapters in ruby, types are declared in the model directory of the project.

A typical Account-model is similar to a rudimentary ActiveRecord-based Model-setup.

module Arcade
  class  Account  < Arcade::Vertex
    attribute :name, Types::Nominal::String
    attribute :mail, Types::Nominal::String

    def self.db_init
      File.read(__FILE__).gsub(/.*__END__/m, '')
    end
  end
end
__END__
CREATE PROPERTY account.name STRING
CREATE INDEX  ON account (name) UNIQUE
## /model/arcade/account.rb

Account is a Vertex
Two attributes are predefined and type-checked via DRY::Types.
One Index is defined. Its needed for filtering.
The code at the bottom of the model-file creates the corresponding database-properties through -> Account.create_type.

First steps

It is assumed, that an arcadedb-server is setup and running.
Initialize a ruby project

mkdir test-project && cd test-project
mkdir bin
mkdir model; mkdir model/arcade
bundle init
bundle add arcadedb

Clone dev-adventures and modify the provides framework to your needs. Modify the provided arcade.yml!

Open the console cd bin && ./console and create the Account-Vertex

3.2.0 :002 > Account
 => Arcade::Account 
3.2.0 :003 > Account.create_type
25.10.(15:51:50) INFO->Q: create vertex type account    
25.10.(15:51:50) INFO->Q: CREATE PROPERTY account.name STRING
25.10.(15:51:50) INFO->Q: CREATE INDEX  ON account (name) UNIQ
3.2.0 :004 > Account.insert name: 'hugo', mail: 'hugo@test.com', age: 37, home: '0098 565 4433' 
 => <account[#1:0]:{0->}{->0}, age: 37, home: 0098 565 4433, mail: hugo@test.com, name: hugo>

Congratulations! You just created the first record. Only essential attributes are predefined. Other attributes are added as needed.

Basic commands

At that point, any database query can be submitted via DB.query "query" or DB.execute { "query" }, eg.

 DB.query 'select from account'
 =>                                                
[{:@rid=>"#1:0",                                  
  :@type=>"account",                               
  :@cat=>"v",                                      
  :mail=>"hugo@test.com",                          
  :name=>"hugo",                                   
  :age=>37,                                        
  :home=>"0098 565 4433"}]

Most common tasks are present via ruby, eg.

a =  Account.find name: 'hugo' # find one record
a.update name: 'danzig'        # does not modify a
a = a.refresh                  # mutate a
=> <account[#1:0]:{0->}{->0}, age: 37, home: 0098 565 4433, mail: hugo@test.com, name: danzig>

This is the first part of an introduction series on ArcadeDB.

Next Part: Ruby Adventures with ArcadeDB 2

Tailwind Carousel in Rails 7

Hartmut B. — Tue, 15 Mar 2022 20:53:11 +0000

After being absence for a while, I recently began to reshape my Rails skills.

A basic Rails7-setup now includes TailwindCSS and TurboFrames.
I designed a simple Website providing a carousel as eye-catcher. Sure – you can copy the code from Tailwind Elements, install the tw-elements javascript-library and anything runs out of the box.

But that's not very rubyish. Each time you want to change something, you have to touch the source-code. I like the approach to have a configuration file, providing input-data for a helper to create the carousel on the fly.

What defines a Carousel

As shown in the Cover Photo (which is taken from the Tailwind Elements Page, we need

an image file
a title
a short description
a link to other content

Configuration in config/carousel.yml

It seems only natural to put anything in a yaml-config-file. Lets create /config/carousel.yml

---
- :first:
    :link:  first
    :image: dizzy-analyst.png 
    :title: Our amazing Approach
    :text:  Explore our unique Solution for all your Problems.
- :second:
    :link:  option
    :image: dizzy-woman.png 
    :title: Feedback
    :text:  We encourage you to provide critical feedback.

The image-files have to be copied into /app/assets/images! Its assumed, that the links just point to anchors on the same page.

The Controller

Assuming, you have setup a User-Resource and want to place the carousel on the Index-Page.

# app/controller/users_controller.rb

class UsersController < ApplicationController
(...)
 def index
    @users = User.all
    @carousel =  YAML.load_file(Rails.root + 'config/carousel.yml')
  end

Its very simple: We define the @users the usual way and read the complete yaml-file into @carousel.

Display carousel in the viewfile

The view-file is evenly simple

# app/views/users/index.html.erb
<header> {some stuff for the header section} </header>
<%= carousel "testCarousel", @carousel %>

....

The hole code is delegated to the carousel-helper.

The code: Carousel-Helper

Essentially the Tailwind Elements -code is translated to fit into Rails-content_tag elements.

# /app/helpers/users_helper.rb

module UsersHelper

  def carusel id,  content
    slides =  content.count

    note = ->(n){ "<h2 class=\"text-4xl\">#{n[:title]}</h2> <p class=\"text-xl\">#{n[:text]}</p> "}

    content_tag( :div, class:  %w( carousel slide carousel-fade carousel-dark  relative ), :"data-bs-ride" => 'carousel', id: id ) do
      content_tag( :div , class: %w( carousel-indicators absolute right-0 bottom-0 left-0 flex justify-center p-0 mb-4 ) ) do
      raw( (0 .. slides).map do | count |
          label =  "Slide #{count + 1}"
          raw(  if count.zero?
           content_tag( :button , nil,  type: 'button', :"data-bs-target" => "##{id}" , :"data-bs-slide-to" => count, :"aria-current" => "true", :"aria-label" => label, class: "active" )
                else
           content_tag( :button , nil,  type: 'button', :"data-bs-target" => "##{id}" , :"data-bs-slide-to" => count, :"aria-label" => label )
                end
             )
        end.join)
      end +
       content_tag( :div, class: %w( carousel-inner relative w-3/2 overflow-hidden ) ) do
        raw( content.map.with_index do | c,index |
          h  = c.values.first
            # first image ist active
            class_attributes = index.zero? ? %w( carousel-item active relative float-left w-full ) : %w( carousel-item relative float-left w-full)
            content_tag( :div, class: class_attributes ) do
              content_tag( :a,  href: "##{h[:link]}" ) do 
              image_tag( h[:image]  , class: %w( block w-full)) +
              content_tag( :div , raw(note[h]), class: %w( carousel-caption hidden sm:block absolute text-center ) )
              end
            end
          end.join)
      end  +
      content_tag( :button, class: %w( carousel-control-prev absolute top-0 bottom-0 flex items-center justify-center p-0 text-center border-0 hover:outline-none hover:no-underline focus:outline-none focus:no-underline left-0 ),
                  type: 'button', :"data-bs-target" => "##{id}", :"data-bs-slide" => "prev") do
                      content_tag( :span, nil, class: %w( carousel-control-prev-icon inline-block bg-no-repeat ), :"aria-hidden" => "true") +
                      content_tag( :span, "Previous", class: "visually-hidden")
                                                                                            end +
      content_tag( :button, class: %w(carousel-control-next absolute top-0 bottom-0 flex items-center justify-center p-0 text-center border-0 hover:outline-none hover:no-underline focus:outline-none focus:no-underline right-0) ,
                  type: 'button', :"data-bs-target" => "##{id}", :"data-bs-slide"=> "next") do
                      content_tag( :span, nil, class: %w( carousel-control-next-icon inline-block bg-no-repeat ), :"aria-hidden" => "true") +
                      content_tag( :span, "Next", class: "visually-hidden")
                                                                                            end
    end


  end
end

Et voila, the carousel is displayed in localhost:3000/users.

Further customization happens in the helper-code (by trained personal). The display-format for title and description, for example, can be changed in the Lambda in row 3.

Conclusion

The goal was, to separate Content and Function. Its just a matter of editing the `config/carousel.yml' file to update the contents of the carousel.

The Art of Initialising Objects

Hartmut B. — Tue, 15 Dec 2020 17:22:01 +0000

Last week, I wrote about Composition in Ruby. A module was used to masquerade the initialization of an Object.

This post introduces another way to simplify programming.

Ruby class names, like their java counterparts, tend to be verbose. They are sometimes easy to remember. Programs -- on the other side -- are sometimes difficult to read.

In the other Post a cryptic Class.new was transformed to a speaking Object-call:

# Previously
> Order.new kind: price: 5, ordertype: :lmt, total_amount: 100
# result
> Limit.order price: 5, size: 100

However, this approach requires some overhead.

A Remind to Stenography

A long time ago, mostly women had the capability to write as fast as one can talk. They substituted long phrases with something they mysteriously could translate to readable words later.

The same technique is useful to clarify ruby scripts, too

A few days ago, I had to write some queries for ActiveOrient. The query-generator is located in OrientSupport::OrientQuery.

For each subquery a new object is created.

In a script, its obvious that one can choose another constant to substitute the long name. This fails if used elsewhere and is truly bad practice.

Lamba's to the rescue

As many modern ruby-classes, OrientSupport::OrientQuery is initialized with a bunch of hash-items.

> query =  OrientSupport::OrientQuery.new  from: TheList, where: {name: 'Maria Hellweg' } )

Define a Lamba

> q = -> (**args){ OrientSupport::OrientQuery.new **args }

Then the simple query can be rewritten

> maria = q[ from: TheList, where: {name: 'Maria Hellweg' } ]
> maria.to_s
 => "select from the_list where name = 'Maria Hellweg' "
> maria.execute (...)

This trick creates a new query-object just by typing q[].

This is must helpful to create standard-queries


> q[ projection: address, from: TheList, where: {name: 'Maria Hellweg' } ].execute
=> "Walddornweg 23"

and it can be nested

>  q[ from: q[ from: TestQuery, where:{ a: 2 , c: 'ufz' } ], kind: 'traverse', projection: :day).to_s
 => "traverse day from ( select from test_query where a = 2 and c = 'ufz' ) "

Conclusion

Commonly lamba's are used to introduce aspects of functional programming to ruby scripts. However, they can create objects as well.
This trick avoids assignments of simple constants to complicated class names. Its a strictly local solution with minimal overhead and without any side effects.

Composition in Ruby

Hartmut B. — Fri, 11 Dec 2020 10:57:35 +0000

As Rubyists prepare for the most anticipated release of Ruby 3.0, its worth looking to unchanged principles.

Composition

One exiting feature of the ruby language is the presence of Modules.

module LimitOrder
  def price
    @price
  end
end
class Order 
   attr :what, :amount
  (...)
end
class StockOrder < Order
  include LimitOrder
  (...)
end

StockOrder inheritances anything from Order and has access to properties and methods of LimitOrder.

include works on instances of an object. Thus, any object generated by Stockorder.new can access the price method.
extend on the other hand includes properties and methods to classes and modules.

Instantiate Objects without publicly calling `new`

Let's design a module OrderPrototype. Its main purpose is to provide a method order, which finally calls Order.new.

module OrderPrototype
  def defaults
   { }
  end
  def order  **fields
    (...)   ## process fields and fillup arguments
    Order.new **arguments
  end
end

The composition process starts by defining a module Limit:

module Limit
 extend OrderPrototype

 class << self
   def defaults
     super.merge { order_type: :limit,  tif: :good_till_cancelled }
   end
 end
end

class << self assigns the following methods to the class-level. defaults are processed by OrderProtoype.order.

Limit.order size: 1, (...) instantiates a specialized Order-Object without inheritance. Other useful order prototypes are Market.order, StopLimit.order a.s.o.

The Limit-object acts as a singleton
masquerading as constructor for conventional ruby objects.

The approach is implemented in: https://github.com/ib-ruby/ib-extensions/blob/master/lib/ib/order-prototypes.rb
and further documented here

ActiveOrient: Universal Store Facility

Hartmut B. — Sat, 03 Aug 2019 19:54:16 +0000

In Part 3 we claimed »Inheritance and the flexibility of the graphical vertex & edge approach open sudden opportunities.« Let's prove it right away.

The power of RID

OrientDB is a »multi model database«, capable to act as a (SQL)RDMS-, a KeyStore- and a Graph-Database. The KeyStore-Design requires the presence of an universal Key, that's RID.

Each record has a RID, each Object is fully identified through its RID. Simple, but powerfull.

> Person.last.rid   => "34:0"
> "#34:0".expand.to_human 
 => "<Person[34:0] (...) >"

Data-items loaded from the database carry their class-id. ActiveOrient autoloads the object and assigns the corresponding ruby-class. Thus any method defined in the model is accessible, any attribute is present as well as any join and any connected edge is waiting to be discovered.

Time Grid

Think of a mesh of date-items, supporting one central goal: Provide an even access-time to any Date of a given time-period, to any item connected to the grid.

This Graph is realized

Jahr -- [MONTH_OF] -- Monat --[DAY_OF]-- Tag --[TIME_OF]-- Stunde

The nodes are crosslinked via GRID_OF-edges and any point of the grid is easily accessed.

To use the time-grid, install the OrientDB-Time-Graph-Gem. It creates the grid and defines a method to_tg for String and Date/Time,

> Date.today.to_tg.datum
 => Fri, 02 Aug 2019 
 #  and 
"4.6.2015".to_tg
 => #<TG::Tag:0x00000000043c8c60 (...)

Store Items

By simply assigning a database-record to the Tag-Object, the universal store facility is created.

Lets go back to our family of Part 3 and assign Seema's birthday. We use a specialized edge-class HAS_BIRTHDAY

> E.create_class :has_birthday
> sema = Child.where( name: 'Seema').first
> "20.6.2010".to_tg.assign vertex: sema, via: HAS_BIRTHDAY

Query

Let's consider two use-cases

we just want to know Seemas birthday
we are interested in all birthdays in June 2010

Seemas Birthday

We can simply get the Child-Record and follow the link to the time-grid.

> sema = Child.where( name: 'Seema').first.to_human
"<Child[147:0]: in: {IS_CHILD=>1, HAS_BIRTHDAY=>1}, name : Seema>" 

> seema.nodes(:in, via: /birth/).datum  # firing a query 
 #or
> seema.in_has_birthday.out                # performs action in ruby
 => [Sun, 20 Jun 2010]

This is similar to an RDMS(SQL)-approach.

Any Birthday in a given range

Suppose, you got a huge database, full of birthdays and want to mine the data. In the RDMS-World you would query the hole database-table. The more data, to longer it takes. Even if you are just interested in People with Birthdays in the same month then Seema, there is no way to avoid accessing all birthday-records in store.

The »Time-Graph« offers constant access time regardless of the size.
We just jump to one boundary of our range of interest and traverse the next 30 day-records.

> start = "1.6.2010".to_tg   
> start.vector( 30 ){ :out_has_birthday }
# INFO->select out_has_birthday from  ( traverse  outE('tg_grid_of').in  from #55:5042 while $depth < 30   )  where $depth >= 0 
 => ["#52:5043"] 
> start.vector( 30 ){ :out_has_birthday }.expand.nodes(via: /birth/).to_human
=> [["<TgChild[147:0]: in: {TG_IS_CHILD=>1, TG_HAS_BIRTHDAY=>1}, name : Seema>"]]

The method »vector« encapsulates the traverse query. We follow 30 time-grid-links (30 days) and are looking for an property »out_has_birthday«. The query returns an array of RID's (of Time-Grid-Elements). We expand them manually and follow the link HAS_BIRTHDAY.

If we are interested in the count of birthday's in a specific range:

> start.vector( 30, function: :count ){ :out_has_birthday } 
 => 1

Conclusion

Database Design matters, even if a flexible multi-model-database is used. This simple pattern opens a door to »sustainable programming«. In contrast to classical RDMS(SQK)-Databases, using a Time-Grid, time-dependent data are stored in an unified environment. Queries are time-invariant. That means: if a database matures, grows and evolves, on can expect constant access times to its heart: the Time-Grid. The possibility of an assignment of any (seriable) ruby object to the time-grid is self evident.

ActiveOrient: Inheritance, Edges and Nodes

Hartmut B. — Wed, 31 Jul 2019 11:50:04 +0000

This is Part 3 of the ActiveOrient Series.

In Part 2 we investigated similarities between RDMS(ActiveRecord)-Joins and unidirectional links and joins in ActiveOrient.

Our example Database consisting of Persons, wo are either father, child or (implicitly) parent enabled queries like

Which are the grandchilds of a father (Person.grandchilds( of: 'Reimund' ) remember?
Who is a father?
Who does not have children.

For now, we stick by our Person class, but organize the data with directional links and introduce inheritance.

Inheritance

In the self-referential approach, a child is a child, because there is a link in the children-property of Person. If we have to decide, if some action is allowed for the Person, we have to query the database and look for those entries. Thats inefficient.

 > Person.create_class :child, :father
  # INFO->CREATE CLASS child EXTENDS person
  # INFO->CREATE CLASS father EXTENDS person
 => [Child, Father]

creates inherit classes. A Child, its a specialized Person. In the model-file (/model/child.rb) we can express this be defining customized methods. As expected, children and fathers are persons:

 > ['Andrea','Susi','Seema'].map  {|c| Child.create name: c}
 > ["Otto","Joseph"].map  { |c| Father.create name: c}
 > Person.count     => 5
 > Father.count     => 2

Instead of querying the database for occurrences of a reference to a person record in Person.children, we just ask for the Class and know, this is a child. To list all children, we don't have to query all persons, we just express Child.query.order(name: :asc).execute. Much better.

The implementation does not require changes to our database-schema. Anything works with self-referential links, as before. And it is still static. So let change this.

Edges and Nodes

The most common feature of a Graph-Database is the presence of Vertices and Edges. Our present approach uses only Vertices.

Edges connect Vertices bidirectional.
Any Vertex has special properties: in and out which are arrays of links to Edges.
ActiveOrient provides a method nodes. It follows the attached edge and lists any Vertex present »on the other side of the Edge«.
Vertices are connected through the method :assign.

Assuming, we want to represent the relationships of persons, created above,

 > E.create_class :is_family
 > IS_FAMILY.create_class :is_child, :is_father
 > hugo =  Person.create( name: 'Hugo')
 > hugo.assign( via: IS_CHILD, vertex: Child.like( 'name = S*'))
 # INFO->select from child where name.left(1) = 'S' order by name asc
 # INFO->CREATE EDGE is_child from #29:6 to [#54:0, #53:0] 
 > hugo.assign( via: IS_FATHER, vertex: Father.where( name: 'Otto'))
 # INFO->CREATE EDGE is_father from #29:6 to [#59:0]
 # then
 > hugo.reload!
 > hugo.nodes( :out, via: /is/).count  => 3
 > hugo.nodes( :out, via: IS_FATHER ).first.name => 'otto'
 > Child.where( name: 'Seema').first.nodes( :in).to_human 
 => ["<Person[29:6]: out: {IS_FATHER=>1, IS_CHILD=>2}, name : Hugo>"]

First, we create inherent Edges: IS_Family, IS_CHILD and IS_FATHER.

Note: In ActiveOrient Edge-Classes are UPERCASE. The database-classes are still lowercase.

»hugo«, a person, is created. The new record is then assigned through IS_CHILD-Edges to any child-record meeting the search criteria. We managed to connect Susi and Seema. This is followed by an assignment of Otto via IS_FATHER.

At last, we queried the relationships. The method :nodes distinguishes between :in-going and :out-going edges. The assignment occurs on the :out side of »hugo«. The :via-parameter filters the edges, either by providing the EDGE_CLASS or an regular expression, which fits the lowercase database class names.
Nodes work in both directions. That's demonstrated in the last query. We start with a Child and ask any relationship. There is only one, to the father-vertex.

Perhaps you get the idea: This is not the end. Its very simple, to investigate the relationships of the father, for instance, to display the grandparents, their children and so on.

Conclusion

Inheritance and the flexibility of the graphical vertex & edge approach open sudden opportunities. ActiveOrient provides some methods to ease the transformation for people (like the author) who thought »relational« their hole life.

This opens many opportunities. As in real life: Its often more comfortable, to live in a well grounded environment with simple rules then to be responsible for a decent path. With ActiveOrient (and OrientDB) the developer can choose, to work with relations or graphs and s/he can benefit from proven layouts from both worlds.

In the next part, we will develop a time-graph, able to efficiently organize any time-based data, events, time-series and more.

ActiveOrient: Joins and Links

Hartmut B. — Mon, 29 Jul 2019 18:54:52 +0000

In the Introduction we created a self-referencing join.
Lets compare with ActiveRecord

# (ActiveRecord) in file /model/person.rb
class Person
  has_many :children, class_name: 'Person', foreign_key: 'father_id'
  belongs_to :father, :class_name => 'Person'
end
# then 
 Person.find( name: 'Hugo').first.father 
 Person.find( name: 'Hugo').first.children

We omited the tricky part of setting up a database-definition, defining proper indices and perform a migration through rake-tasks and note, that data have to be inserted, too.

Insert Data

With ActiveOrient, we just create the database-table, insert our data and are done.

> V.create_class :person
> hugo = Person.create name: 'Hugo', 
                       father: Person.create( name: "Reimund" ),
                       children: ["Eva", "Ulli", "Uwe", "George"].map{|c| Person.create( name: c) }
=> "<Person[150:0]: children: [#146:0, 147:0, #148:0, #149:0], father : <Person[145:0]: name: Reimund>, name: Hugo>" 

> hugo.father.name   => "Reimund"
> hugo.children.name => ["Eva", "Ulli", "Uwe", "George"]

Note that children are represented by their database-id's only, this is equal to the foreign_key used by ActiveRecord.

The schemaless approach reveals a quick solution and exposes the basic functionality of a comparable RDMS-Database. But there are limits. The possibility to work schemaless does not mean, that ad-hoc designs are favorable. It is, for instance, not possible, to query linked records, unless a proper schema is defined. We are still in the database-world, the world of structured data.

Define Properties

It is a good practice, to put an index on any property, which is subject of a query. We want to create a notunique-Index on the :name property. :children are just a list of links, containing Person objects and
the :father is a linkto a Person-record. But first, lets delete anything.

> Person.delete all: true
> Person.create_property  :name, type: :string, index: :notunique
> Person.create_property  :children, type: :link_list, :linked_class: Person
> Person.create_property  :father, type: :link, linked_class: Person
# check
> Person.print_properties
  Detected Properties for class person
    person.children -> LINKLIST -> person
    person.father   -> LINK -> person
    person.name     -> STRING

To insert another record, we must avoid to create a duplicate of the Reimund-Person.

pete = Person.create name: 'Pete', 
                     father: Person.upsert( where: {name: "Reimund"} ),
                     children: ["Eva", "Mathew" ].map{|c| Person.create( name: c) }

Instead of creating a new record for the father, we search the database and use the existing entry. Upsert inserts a record if no entry is found. That guarantees that :father is always a valid link.

Query the Database

Orientdb Database classes and -records are queried with a SQL dialect. ActiveOrient provides a method query to build such queries similar to ActiveRecord.

> Person.query.where( "father is NOT NULL" ).execute.name
 #INFO->select from person where  father is NOT NULL 
 => ["Peter", "Hugo"] 
> Person.query.where( 'father.name' => 'Reimund' ).projection('name').execute
 #INFO->select name from person where father.name = 'Reimund' 
 => [{:name=>"Pete"}, {:name=>"Anton"}]

The first query returns two Person-records. We display only the property :name. The second query specifies a projection and returns a list of hashes.

Model-helper

Complex queries can be stored in the model-file of the class. Queries are class-methods. Thus, in /model/person.rb

 class Person
  def self.grandchilds of:
    query.where('father.name' => of)
         .projection( :children )
   end
 end

The class method returns a OrientQuery. It can further modified, inspected by calling to_s and finally executed.

> Person.grandchilds( of: 'Reimund' ).execute.to_human
# INFO->select children from person where father.name = 'Reimund' 
["{ children: #29:5#30:5#31:5#32:4 }", "{ children: #26:5#27:5 }"]
# or
Person.grandchilds( of: 'Reimund' ).execute{|y| y[:children]}.name
 => ["Eva", "Ulli", "Uwe", "George", "Eva", "Mathew"]

For pre-prosessing OrientQuery.execute exposes any returned record to the optional block. Obviously, we are interested in :children. The query returns links to Person-Objects which are expanded by ActiveOrient. Thus .name simply addresses the name-attribute of the returned records.

Conclusion

The database has basic support for joined tables. Anybody familiar with RDMS-(SQL)-Databases should be comfortable with unidirectional links and joins and their ActiveRecord-like querying. We can develop a draft sketch (schemaless) without any configuration. If necessary, constrains, properties, indices and validations are added. The power of nested projections goes far beyond anything in the RDMS-world.

ActiveOrient combines the power and beauty of ruby with SQL for the 21st Century.

Unidirectional Links and Joins are nice and familiar. In the next part, we extend this approach to bidirectional Links and take a walk into the world of graphs.

Active Orient – Introduction & Overview

Hartmut B. — Wed, 24 Jul 2019 10:46:17 +0000

How about a (fast) open source database usable without any schema, query-able with sql-statements and able to perform sophisticated graph operations? Not to forget: Easily accessible via an intuitive ruby interface. The latter is ActiveOrient.

Prerequisites

Install the database ( Download the OpenSource Database) and assign a Username
Make sure that ruby 2.6 is installed (via snap or rvm). Check if bundle is installed (otherwise gem install bundle)
Clone the ActiveOrient git archive and bundle ruby libraries:

git clone https://github.com/topofocus/active-orient.git
cd active-orient
bundle install; bundle update

Now modify config/connect.yaml.
Test, development and production databases are created if they don't exist.

Then change to /bin and run

./active-orient-console -t

Simple Start

Any database-class is recognized and allocated. Further, any class created in the process is usable immediately. The behavior of any Class can be customized in model-files, which are included upon the creation of a class.

The base-classes V)ertex and E)dge are always present. Its good practice, to inherent any user-class from the base-classes.

 # create a class
    V.create_class :m   # V is the base »vertex» class. M is the vertex-class created The corresponding database-class: »m«.
 # INFO->CREATE CLASS m EXTENDS 

 # create a record
    M.create name: 'Hugo', age: 46, interests: [ 'swimming', 'biking', 'reading' ]
 # INFO->CREATE VERTEX m CONTENT {"name":"Hugo","age":46,"interests":["swimming","biking","reading"]}
    # query the database
    hugo = M.where( name: 'Hugo' ).first
    hugo.to_human
    =>"<M[177:0]: age: 46, interests: [\"swimming\", \"biking\", \"reading\"], name : Hugo>" 
    # update the dataset
    hugo.update father: M.create( name: "Volker", age: 76 )  # we create an internal link
# INFO->CREATE VERTEX m CONTENT {"name":"Volker","age":76}
# INFO->update #177:0 set father = #178:0
    hugo.to_human
    => "<M[177:0]: age : 46, father : <M[178:0]: age : 76, name : Volker>, interests : [\"swimming\", \"biking\", \"reading\"], name : Hugo>"
    hugo.father.name    
    => volker
    # change array elements
    hugo.interests << "dancing"  # --> [ 'swimming', 'biking', 'reading', 'dancing' ]
#INFO->update #177:0  set interests = interests || ['dancing'] 

    M.remove hugo 
    M.delete_class  # removes the class from OrientDB and deletes the ruby-object-definition

In this brief introduction, we created a Vertex-Class »M«. Then we created a document (record) with some properties. We queried the database using a syntax similar to ActiveRecord.
Then we created a self-refrencing link which we followed to access connected information.

At last – using the syntax of ruby-arrays – we added an entry to an embedded list. Anything without any configuration in schema-, model-files or whatsoever.

This ends Part 1 of the ActiveOrient Mini-Series.
The next part covers unidirectional links and joins, an introduction to sql-queries and their abstraction with Orientquery

Sex	Vorname	Name	Ort	Straße
Frau	Maria	Gross	Lüneburg	Hauptstr. 12a

DEV Community: Hartmut B.

ArcadeDB, Ruby && Jupyter

Customization

Advanced Visualization && Calculations

Ruby Adventures with ArcadeDB 2

Some Basics

The Power of RID

Exploring the Structure

Bidirectional connections – with attributes

Ruby Adventures with ArcadeDB

First steps

Basic commands

Tailwind Carousel in Rails 7

What defines a Carousel

Configuration in config/carousel.yml

The Controller

Display carousel in the viewfile

The code: Carousel-Helper

Conclusion

The Art of Initialising Objects

A Remind to Stenography

Lamba's to the rescue

Conclusion

Composition in Ruby

Composition

Instantiate Objects without publicly calling new

ActiveOrient: Universal Store Facility

The power of RID

Time Grid

Store Items

Query

Seemas Birthday

Any Birthday in a given range

Conclusion

ActiveOrient: Inheritance, Edges and Nodes

Inheritance

Edges and Nodes

Conclusion

ActiveOrient: Joins and Links

Insert Data

Define Properties

Query the Database

Model-helper

Conclusion

Active Orient – Introduction & Overview

Prerequisites

Simple Start

Instantiate Objects without publicly calling `new`