Scala DSL

[evanvelikanov]

One thing I missed having in OrientDB was Scala-specific APIs which allow using precision in verbalizing thoughts into code in less, yet type-safe, elegant, and maintainable fashion. Once people go into the line they expect that. And having scala support is good because a lot of development and talent nowadays is in Scala. For example, I really wanted to write React code in a typesafe way but in a JVM language. Java has JSweet it is quite okay-ish but very few Github stars. Kotlin-js is new. Scala-js is very popular, battle-tested, and has a lot of GitHub stars. In JVM languages the cutting edge is happening in Scala is what is my experience. Java might be the base for JVM languages, but Scala is where the most talented people are there. Plus you get paid more to be a Scala developer. These are my thoughts based on personal experience, and no way intended to praise one and discredit another. I could say I am biased openly. So I advise prioritizing this ticket based on what makes sense for the organization.

[lvca]

Hi @ivan-velikanova, thanks for the proposal. WDYT about you getting started with this project? I'm trying to build a community here outside the committers around the engine :-)

[evanvelikanov]

I am excited to use this frankly. But I am not the best person to tell sorry. The reason being today I planned to start on one of the NGO (related to human rights work/genocide) projects, but today another human rights violation emergency case came and I don't have time to work on this project. My core work is not coding, unfortunately.

[lvca]

@ivan-velikanova What are your requirements for working with Scala language and using a DBMS?

[evanvelikanov]

The basic API is ok
These are not requirements per se, but some good to have things would be
-- Query API/DSL - something like quill or jooq ; both JOOQ and Quill are very elegant. Quiet different approaches, and domain, and quite different pros and cons ... but since Arcade/Orient is multi-model i am mentioning both. Right now I don't think Arcade/Orient has an implementation in either.
-- to do things like mapping scala case classes/POJO/DTOs to and from ODocument
-- to make schema from code like -- db.createVertexClass("Person"); ... this whole thing feels a quite old style thing. no builder pattern. Scala AST manipulation can do it quite elegantly, this is missing, it makes orient look like not a part of the scala ecosystem, looks like a typical java library.

I like the JOOQ philosophy of a single source of truth, as is not the code but the schema. The java code for the database is generated from the schema. I am saying the other way is also not the issue, but that should be some consistency and vision in this. The requirement and our understanding of the problem keep evolving the database schema keeps evolving. So I should update either the code or the schema and others should get updated. So which approach we take I am not thinking too much about it, but I should not need to sync between schema and code basically. I am not even thinking along the lines of having annotations in the type definitions/case classes/DTOs and making a schema from that. I am just saying there should be singe source of truth. This is more apt for a strict schema, but I feel in java and scala people like thins strongly typed way of thinking rather than strongly, I should be able to get suggestions right inside the IDE.
I tried to make a DSL last year, like a hobby, finally, I didn't have time.

Personally, I think I would like to be able to define the entire db in pure code. So it will be scala case classes completely sealed. And all cases will be defined, and I should be able to do a switch on the db records. With java 17 they kind of added this in java also. Scala will be next level always because of compiler macros and several other features.