ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tal Liron (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ARIA-180) Convert many-to-many for parameter models to one-to-many
Date Tue, 02 May 2017 16:07:04 GMT
Tal Liron created ARIA-180:
------------------------------

             Summary: Convert many-to-many for parameter models to one-to-many
                 Key: ARIA-180
                 URL: https://issues.apache.org/jira/browse/ARIA-180
             Project: AriaTosca
          Issue Type: Story
            Reporter: Tal Liron
            Priority: Minor


We must first discuss this as a team to see if we agree that this is the best solution. (There
was an early discussion between Tal and Maxim.)

First let's point out that one-to-many is a special case of many-to-many, so that everything
works fine now and continue to work fine.

However, logically our code right now treats them as one-to-many: there is no case in which
a {{Parameter}} model belongs to more than one model. Parameters are always copied to the
new model, for example during instantiation, or during task creation.

There are cons to using many-to-many in our case:

* We generate lots of extra secondary tables, one for each potential relationship
* Crawling back from a `Parameter` to its containing model is quite costly, as it involves
a new SQL query to check for each possible relationship
* Logical confusion: if we do not write our code to support one parameter belonging to one
model, and yet a user can create such a relationship, what would happen?
* Slower

The one advantage of many-to-many is that we *could* potentially optimize in some cases where
the parameter has an identical value and we know would never change, and thus could safely
link it multiple times instead of copying it. This optimization, however, requires us to be
100% sure that the parameter is immutable: otherwise, if a user changes it (for example in
a task) it would change for all other containers. The questions are: 1) are we ever sure of
immutability? and 2) is this optimization worth the effort of implementing it? The optimization
would only seem to save some disk space.

If we decide to switch to one-to-many, we have two approached:

* Straightforward: one foreign key in {{Parameter}} per each possible containing relationship.
Pros: naturally supported in SQL, cons: we will have lots of fk columns per row in the {{Parameter}}
table, whereby only one will be non-null.
* Polymorphic one-to-many (type-and-id joins): {{Parameter}} only has a single general-purpose
fk column and another column specifying the type of the fk (node, interface, task, etc.).
Cons: we would need to investigate how to accomplish this in SQLAlchemy.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message