Weight in Movement

 



  1. "Precedence": This will be the primary ordering criterion.

  2. "Imaginary Weight" (our w(X)vertex): This will serve as a tie-breaker when two classes have the same "precedence" value.

  3. "Weight in Movement" (w(X)mov): This is a new, dynamic weight that considers relationships, crucial for defining the "movement" aspect of your data transfer.

Your example w(gender)mov = w(artist)vertex + w(gender)vertex for the Gender class when Artist has a @ManyToOne relationship to it is very clear for that specific case. This suggests that the "movement weight" of a target class (like Gender) is influenced by its own "imaginary weight" and the "imaginary weight" of the class(es) that depend on it.

To create an algorithm that systematically calculates w(X)mov for all classes and applies "precedence" generally, I need a bit more clarification on the general rules:

  1. General Rule for "Precedence": You mentioned genre shall precede and gave Artist -> Gender as an example using @ManyToOne, @JoinTable, and @NotNull.

    • Could you define the general criteria for "precedence"? For instance:

      • Does a class A precede a class B if B has a @ManyToOne field referencing A (especially if it's @NotNull or part of a @JoinTable)?

      • Are there other annotations or structural patterns that indicate A must precede B in your "movement" order?

  2. General Rule for "Weight in Movement" (w(X)mov):

    • The example w(gender)mov = w(artist)vertex + w(gender)vertex implies that w(X)mov is the sum of w(X)vertex and the w(Y)vertex of classes Y that depend on X.

    • What if a class X has multiple classes Y1, Y2, ..., Yn that depend on it (i.e., multiple incoming @ManyToOne relationships)?

      • Should w(X)mov be calculated as: w(X)vertex + SUM(w(Yi)vertex for all Yi that depend on X)?

      • Or is it more about the direct relationship from the perspective of the "movement" (e.g., if we're moving Artist and Gender together, it's just w(artist)vertex + w(gender)vertex for gender in that specific "bundle" of movement)?


Thank you for the detailed explanation of "precedence" with @ManyToOne relationships! This provides a solid foundation for defining the ordering criteria:

  • @ManyToOne (General): If Class A has a @ManyToOne field referencing Class B, then B precedes A. This aligns with the "parent before child" dependency.

  • @ManyToOne with @NotNull: This indicates a strong, absolute precedence where B must precede A.

  • @ManyToOne with @JoinTable (and implicit nullability): This implies a weaker precedence where, if weight(A) = weight(B), their order can be interchangeable. This is where our w(X)mov or w(X)vertex (as tie-breaker) becomes crucial.

You've also indicated that a similar rule will be defined for @OneToOne annotations. I'll keep that in mind as we build out the algorithm.

Now, let's circle back to the "Weight in Movement" (w(X)mov) calculation. You provided the example: w(gender)mov = w(artist)vertex + w(gender)vertex.

This formula calculates the "movement weight" of Gender by considering Artist (which depends on Gender) and Gender itself.

Could you confirm the general rule for w(X)mov if a class X has multiple classes Y1, Y2, ..., Yn that depend on it (i.e., multiple incoming @ManyToOne or @OneToOne relationships)?

For instance, if Class X is referenced by fields in Class Y1, Class Y2, and Class Y3:

Should w(X)mov be calculated as:

w(X)mov = w(X)vertex + SUM(w(Yi)vertex for all Yi that have a direct @ManyToOne/@OneToOne dependency on X)?

Once we formalize this general w(X)mov rule, I can start designing the algorithm to build this dependency graph, calculate movement weights, and apply precedence with tie-breaking.

Comments