You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently OneToManyRelations and OneToOneRelations are simply stored with a #{index} post-fix, where the index runs from 0 to the number of total relations, starting with the OneToManyRelations. This makes it very hard to interpret the branches in the produced root output file. A similar problem exists for the VectorMembers, where the post fix is _{index}.
When working directly with the root files it might be nicer to have more intelligible branch names, e.g. something like #{relation_name}.
Opening this issue here to not forget about it and also to maybe gather feedback into what the best solution would be here. Currently we run the danger that people "circumventing" the EventStore rely upon the order of the relations, when implementing their solution, but this order is basically an implementation detail. Some people are already using this, so it might be good to either make it very explicit that this is indeed an implementation detail that can change without outside warning, or to make this part of the "API" by using more verbose branch names.
One of the open questions that would need to be answered first is whether it is actually possible to use other branch names at all. It is not yet entirely clear to me whether this is possible and how much work it would be to implement it.
The text was updated successfully, but these errors were encountered:
Currently
OneToManyRelations
andOneToOneRelations
are simply stored with a#{index}
post-fix, where theindex
runs from 0 to the number of total relations, starting with theOneToManyRelations
. This makes it very hard to interpret the branches in the produced root output file. A similar problem exists for theVectorMembers
, where the post fix is_{index}
.When working directly with the root files it might be nicer to have more intelligible branch names, e.g. something like
#{relation_name}
.Opening this issue here to not forget about it and also to maybe gather feedback into what the best solution would be here. Currently we run the danger that people "circumventing" the EventStore rely upon the order of the relations, when implementing their solution, but this order is basically an implementation detail. Some people are already using this, so it might be good to either make it very explicit that this is indeed an implementation detail that can change without outside warning, or to make this part of the "API" by using more verbose branch names.
One of the open questions that would need to be answered first is whether it is actually possible to use other branch names at all. It is not yet entirely clear to me whether this is possible and how much work it would be to implement it.
The text was updated successfully, but these errors were encountered: