Add foreign keys for data consistency

[akalongman]

Would be great if we add foreign keys. For example I use custom migration file with schema like this:

Schema::create(self::getTableName(), static function (Blueprint $table) {
    $table->id();
    $table->unsignedBigInteger('entry_edge_id')->nullable()->comment('The ID of the incoming edge to the start vertex that is the creation reason for this implied edge; direct edges contain the same value as the Id column');
    $table->foreign('entry_edge_id')->references('id')->on(self::getTableName())->onDelete('cascade');
    $table->unsignedBigInteger('direct_edge_id')->nullable()->comment('The ID of the direct edge that caused the creation of this implied edge; direct edges contain the same value as the Id column');
    $table->foreign('direct_edge_id')->references('id')->on(self::getTableName())->onDelete('cascade');
    $table->unsignedBigInteger('exit_edge_id')->nullable()->comment('The ID of the outgoing edge from the end vertex that is the creation reason for this implied edge; direct edges contain the same value as the Id column');
    $table->foreign('exit_edge_id')->references('id')->on(self::getTableName())->onDelete('cascade');
    $table->unsignedBigInteger('start_vertex')->comment('The ID of the start vertex');
    $table->unsignedBigInteger('end_vertex')->comment('The ID of the end vertex');
    $table->unsignedTinyInteger('hops')->comment('Indicates how many vertex hops are necessary for the path; it is zero for direct edges');
    $table->string('source', 50)->index()->comment('A column to indicate the context in which the graph is created; useful if we have more than one DAG to be represented within the same application  CAUTION: you need to make sure that the IDs of vertices from different sources never clash; the best is probably use of UUIDs');
    $table->timestamps();
});

[telkins]

Hi @akalongman ,

Thanks for the suggestion. I may be missing something, but the problem with doing something like this would be that it would limit what could be managed. It sounds like you might only manage resources from a single table, but not everyone does this.

The idea behind the source field is to "indicate the context in which the graph is created" and is "useful if we have more than one DAG to be represented within the same application."

So, there's a trade-off either way. In the current case, one has the ability to represent (by table) more than one DAG within the same application. If foreign key constraints are introduced, then one would enjoy the benefits one gets with those, but one would then be tied to a single table within your DB.

While writing this, I considered the possibility of having both, but it would require a significant overhaul:

• refactor the package to support multiple DAGs
• it could be similar to Laravel's database connections, where there's a default configuration and then additional DAGs could be configured
• users with one DAG would use like they do today, presumably
• users with more than one DAG would use it like with Laravel's multiple database support: DB::connection('my-other-db')->whatever()

So...maybe there's a solution here after all...? And, to be honest, I would like to see/use it, because the DAGs I use can get quite large and complex and there's some additional code to manage certain aspects...so foreign keys would help out and alleviate some of the additional "overhead".

I'm curious to hear what your thoughts are on this?

Thanks

[akalongman]

It sounds like you might only manage resources from a single table, but not everyone does this.

What do you mean? These columns (edges) used only for in-table purposes according to DAG specification. For external identificators are columns start_vertex and end_vertex and these fields does not have foreign keys

[telkins]

It sounds like you might only manage resources from a single table, but not everyone does this.

What do you mean? These columns (edges) used only for in-table purposes according to DAG specification. For external identificators are columns start_vertex and end_vertex and these fields does not have foreign keys

LOL! I guess I should look a little more closely at your code. 😆 Sorry, but I read what you wrote and saw some foreign key stuff in the code so I connected the wrong dots. 😅

Anyway, it sounds pretty reasonable. I'm super busy right now, but I'll try to take a close look at it before too much time passes. 🤓

[akalongman]

I will send a PR 😄