For a class with a declared @Edge annotation, there is no need to store any type-related properties/columns, because it causes numerous issues & inefficiencies (for graphs)

[haqer1]

For a class with a declared @Edge annotation, there is no need to store any type-related properties/columns, because it causes numerous issues & inefficiencies (for graphs), such as:

1. waste of disk space
2. waste of memory
3. unnecessary band-width utilization
4. waste of CPU cycles
5. issues 1 -through- 4, can lead to considerable & even noticeable increase in latency (responsiveness)
6. issues 1 -through- 4, (especially when using a Platform as a service) eventually (for a PaaS, quite quickly) translate to additional operating expenses
7. absurd clutter when looking at the data
8. issue 7 will most likely have a negative effect on developer & DB admin productivity: by inhibiting concentration on useful data due to presence of a lot of useless data
   etc.

[haqer1]

PR #72 fixes this.

[haqer1]

As can be seen on the following page, all the automated tests pass:
https://haqer1.github.io/arangodb-spring-data-rational/docs/branch/optimization_for_edges_and_graph_traversal/auto-testing/modified/surefire-report.html
For comparison, the same report for upstream:
https://haqer1.github.io/arangodb-spring-data-rational/docs/branch/optimization_for_edges_and_graph_traversal/auto-testing/original/surefire-report.html

P.S. I.e., there are no issues in PR #72 (the PR for this issue), only optimizations (making stuff better).

[christian-lechner]

As can be seen on the following page, all the automated tests pass:
[...]
P.S. I.e., there are no issues in this PR, only optimizations (making stuff better).

Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. - Edsger Wybe Dijkstra

---

I don't think it's a good idea to remove the type information from @Edge classes. It's the same for them as for @Document classes:

@Edge("relationships")
public class Relationship {
  @From
  private Individual from;
  @To
  private Individual to;
}
public class Child extends Relationship {
  private boolean isAdopted;
  // ...
}
public class Friendship extends Relationship {
  private Instant friendsSince;
  // ...
}

Such a use case is then no longer supported.

[haqer1]

Everybody at ArangoDB has had enough of weird examples. If there is a automated test that is valid, & doesn't pass with PR 72, check it into the repository.

Such a use case is then no longer supported.

False: PR #72 (the PR for this issue) doesn't touch children of a class that declares @Edge annotation (which do not declare @Edge themselves). Thus, if Spring Data ArangoDB supported that, this PR wouldn't affect it.

Child & Friendship above are not usable for traversal[1], which means they are useless as @Edges[2]. And if they are used as equivalents of @Document, then those kinds of workflows work just fine, as can be seen, for example, in
EdgeConstructorWithFromToParamsTestEntity in
https://github.com/haqer1/arangodb-spring-data-rational/blob/2.1.7.1-rational/src/test/java/com/arangodb/springframework/core/mapping/ArangoMappingTest.java
Test for which (edgeConstructorWithFromToParams, line 1060) passes:
https://haqer1.github.io/arangodb-spring-data-rational/docs/branch/optimization_for_edges_and_graph_traversal/auto-testing/modified/surefire-report.html

P.S.
[1] ArangoDB doesn't traverse children of an @Edge. And even if such absurd got added to it, i might consider coding for it the same as for Documents in the future: but right now, it's not supported, & nobody needs this kind of thing anyway, so it can have type info in child classes for all i care.
[2] Which in turn really means, IMHO, this should even be reported to developers at run-time as an initialization error: but i don't have time for that. I only want clean records in my DB.
P.P.S. So, i hope nobody wastes anybody's time. If there is a bug, one can prove it's presence with an automated test case. At present, all tests pass, so this is good to go.
P.P.P.S. If this is sabotaged as for @Documents, you know my answer. I'll use a rational implementation anyway (until this non-sense is cleaned up at ArangoDB):
https://github.com/haqer1/arangodb-spring-data-rational/
In fact it's already in 2.1.7.1-rational.

[mvollmary]

I think a selective storage of type information is the wrong approach. This is neither easy to understand nor easy to maintain for a developer using Spring Data without having all the background knowledge.

[haqer1]

I think a selective storage of type information is the wrong approach.

@mpv1989: Are you insane? There is no "selective storage of type information" in PR #72. All classes with a declared @Edge annotation can, should, & really must be persisted without fully-qualified class name stored in the DB record. Do you understand the meaning of the word "all" (as opposed to "some")? Or is it all a blur to you?

As i've mentioned (#71 (comment)), PR #72 is already in
https://github.com/haqer1/arangodb-spring-data-rational/ since 2.1.7.1-rational release (because (even though i still can't believe it's happened) i had expected shady business again).
Given this expected madness, i've also added this shameless irrationality now in ArangoDB spring-data to the list of issues optimized by arangodb-spring-data-rational:
https://haqer1.github.io/arangodb-spring-data-rational/#edge

If Mark Vollmary does not give a reasonable explanation for this very suspicious, irrational, & really crazy behavior, & if he doesn't push into the git repository a realistic test case which wouldn't pass with PR #72 merged, he too will be a self-certified "agitateur professionnel" (again borrowing a phrase from Emmanuel Macron) (and this has to be done within a reasonable time frame, i.e. within days (at most within a week), not next century or in 10 years)). If you there is no realistic test case for which fully-qualified class name is required in the DB records, then it's totally insane to store this stuff in the DB:
https://haqer1.github.io/arangodb-spring-data-rational/#inefficiencies_optimized

P.S. @MrPieces: So this is the 3rd PR of mine that Mark Vollmary has sabotaged. And unlike last time, although 18 days had passed before his irrational closing of PR #72 and this issue, this time he hasn't even been able to "produce" a perverted example justifying the sabotage (or have it produced by somebody). And each time his behavior has been more and more suspicious, & this 3rd time it has been totally insane. As i've mentioned before, there has to be a really big reason for all this shady business. And this question should interest ArangoDB's senior management, owners, & venture capital providers (among others)...

[MrPieces]

well, @haqer1 ...If there is one thing I learned in my life, then that people who scream are not the ones I listen to.