String Ids

[francisco-polaco]

Hi,

I was wondering what could be done to support string ids and what is the effort for it. Could you comment on it?

Thanks, Francisco

[pietermartin]

Sqlg does support string ids, sortof. But you have to define the schema upfront then with,

        VertexLabel aVertexLabel = this.sqlgGraph.getTopology().getPublicSchema().ensureVertexLabelExist(
                "A",
                new LinkedHashMap<String, PropertyType>() {{
                    put("stringId", PropertyType.varChar(100));
                    put("name", PropertyType.STRING);
                }},
                ListOrderedSet.listOrderedSet(Collections.singletonList("stringId"))
        );
        Vertex a1 = this.sqlgGraph.addVertex(T.label, "A", "stringId", "a", "name", "namea");
        this.sqlgGraph.tx().commit();

        Vertex a = this.sqlgGraph.traversal().V().hasId(RecordId.from(SchemaTable.from(this.sqlgGraph, "public.A"), Collections.singletonList("a"))).next();
        Assert.assertEquals(a1, a);

This will create the table with stringId as the primary key.

Let me know if this will not work for your usecase.

[francisco-polaco]

I believe my problem is a little deeper.

I'm trying to emulate the nodes and edges tables using views of my own data. Since I cannot have "real" IDs, that is, primary keys. I'm trying to have some sort of concatenation of ids of the existing data. So I believe, it's more close to user defined IDs, but actual table IDs and not properties.

Do you believe that it's possible?

[pietermartin]

Not quite understanding, do you want Sqlg to work of existing tables?

[francisco-polaco]

Yes.

Currently, I want to create views on top of my records to "emulate" Sqlg's vertex and edge tables.

[pietermartin]

Ok, afraid that won't work, Sqlg hardcodes its database layout. There is no abstraction layer to decide naming conventions and what edge foreign keys should look like.

[francisco-polaco]

I'm currently surfing Sqlg code. To have an idea, how much effort would it take to make it work? Would it require some major refactor?

[pietermartin]

Yeah a very major refactor. The biggest obstacle will be constructing the joins for the edges. There will need to be a whole abstraction layer to construct joins via arbitrary columns.

[francisco-polaco]

Could you point where are the join queries built, on the code?

[pietermartin]

Most of the logic is in SchemaTableTree.constructSql(LinkedList<SchemaTableTree> distinctQueryStack) Quite a lot happens before that but that's where the queries get constructed.

[pietermartin]

Closing this for now, feel free to open it again.