Question: Is it possible to use a schema with in-memory storage

[RAndrews137]

OrientDB Version, operating system, or hardware.

• v2.0 SNAPSHOT[ ] - .18[ ] .17[ ] .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
• v2.1 SNAPSHOT[ ] - .16[ ] .15[ ] .14[ ] .13[ ] .12[ ] .11[ ] .10[ ] .9[ ] .8[ ] .7[ ] .6[ ] .5[ ] .4[ ] .3[ ] .2[ ] .1[ ] .0[ ]
• v2.2 SNAPSHOT[x] - .rc1[ ] .beta2[ ] .beta1[ ]

  Operating System

• [x] Linux
• [ ] MacOSX
• [ ] Windows
• [ ] Other Unix
• [ ] Other, name?

  Expected behavior and actual behavior

Expected: create an in-memory database but able to leverage schema definitions Actual: Able to create in-memory database but unsure how to add schema definitions

Steps to reproduce the problem

Create an in-memory database using Java

[lvca]

Absolutely. What's the problem?

[RAndrews137]

Here's our scenario, we will have schema defined for our Development, Staging, and Production db instances such as Classes, Properties, Indexes, etc. We want to use the in-memory option for unit tests. After the tests are finished, there is nothing to clean up. However, we would like the in-memory db to have the same schema as the plocal instances. Not sure to inject schema definitions for in-memory without executing SQL statements one by one. Any ideas?

[lvca]

You can create the schema of in-memory database with SQL or API. The only thing is that once last session is closed it could be dropped if you work with plocal.

[RAndrews137]

Is there a way to export a plocal db into sql statements which can be executed? I know that the export UI can dump the database but that is not really something that can be imported into in-memory, can it? Just trying to think of way to take schema from plocal and get it into an in-memory instance.

[smolinari]

This is going to be a bit off-topic of sorts. Sorry for the slight tangent and thread hijacking. But, I think it could be a good point to make now.

The concern this thread raises is one of the reasons why we are looking for a pure NoSQL solution, similar to like MongoDB offers (but with relational data of course!!!). The major "trick" MongoDB offers is, if you insert a document into MongoDB and the collection is new to MongoDB, it automatically creates the collection for you. If you insert properties into a document, and those properties are new, MongoDB also creates the properties for you (ODB can do this too!). In other words, the data being input into the database defines the schema automatically. This allows for the object relational impedance mismatch to be avoided. This also means there is no longer the problem of schema migration or versioning.

This blog series explains the huge advantages for development much better. https://www.mongodb.com/blog/post/mongodb-vs-sql-day-1-2 https://www.mongodb.com/blog/post/mongodb-vs-sql-day-3-5 https://www.mongodb.com/blog/post/mongodb-vs-sql-day-14

So, with this kind of "on-the-fly" schema building, development within a memory only ODB is simple, because the schema is created directly with inserting of data through the code. As MongoDB puts it, "Data is schema". This offers great advantages, which most people don't get, when they move to MongoDB. When it finally clicks with some people, they find it hard to go back to developing any RDBMS (even with ORMs).

I am hoping that ODB can offer this "MongoDB like" NoSQL on-the-fly schema building in version 3.0. I haven't mentioned this idea in a proper suggestion yet, but I will soon. I believe ODB isn't too far away from getting it done. It just needs the automatic creation of classes and indexing on properties not definied by schema. This could help ODB catapult to the top.

Scott

[lvca]

@RAndrews137 unfortunately there is no tool that create the SQL steps to recreate the database, but the export/import should do the job.

[lvca]

@smolinari what do you mean with schema in MongoDB?

[smolinari]

@lvca - There is no schema in MongoDB. That is the important point. :smile:

When you have time, please read the blog posts I linked to above on what it means to develop without schema, or rather how the schema is determined mainly through the data in the code (there must always be some schema somewhere). It would be cool when ODB works as a proper NoSQL database, like MongoDB.

For instance, when I declare

CREATE VERTEX Car SET brand = 'Fiat', model = 'Cinquecento'

Then ODB looks for a class "Car", if it isn't already created, ODB creates the class and extends it from V (because we are creating a vertex) automatically. The two properties "brand" and "model" are also automatically added to the "Car" class with the values given.

ODB is almost there. We just need the automation of class creation and extention of V. :smile:

Scott

[lvca]

@smolinari I don't see this as a big deal: usually you know the type of records you're going to use beforehand. So a create class Car extends V can be executed when you create the database or at application startup. Instead, allowing automatic creation of classes at the fly could be dangerous in some case where you misspelled the class name and you end up with runtime errors of records not found, just because they were stored on different classes. Anyway this is very easy to support, we could provide a global configuration for this.

[smolinari]

If the code started causing errors because of a misspelled class name, then it will cause those errors no matter how the class is created, right? I mean, I can just a well spell the class wrong in CREATE CLASS as I could in CREATE VERTEX or CREATE EDGE.

What we need is the ability to create internal data structures without the DDL, which is normally necessary to create internal data structures. For instance, CREATE CLASS or CREATE PROPERTY shouldn't be needed at all. :smile:

If you feel this important concept of NoSQL could be easily done within ODB, but with a global setting, that would be great too. :+1:

Still, also think about the all the new possibilities. For instance, the request in this thread to be able to create an in-memory database for testing, but without having to migrate any schema, would be a piece of cake. The tests only have to do inserts and away it goes. Also, and more importantly, code working with an ODB database wouldn't be schema version dependent. That is the real big win!

Also, please don't forget to allow for indexing on non-schema defined properties!!! Very, very important to make ODB a proper NoSQL solution! :stuck_out_tongue_closed_eyes:

Scott

[RAndrews137]

For now, we are building our own utility to export out the schema from a known db, and will try to put that into statements which can be used against an in-memory db.

[RAndrews137]

We were able to add schema via in-memory but that involved executing commands to create the schema. Longer term, it would nice if there was a way to inject schema via JSON or something.