[
https://issues.apache.org/jira/browse/ARIA-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avia Efrat reassigned ARIA-180:
-------------------------------
Assignee: Avia Efrat
> 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: Task
> Reporter: Tal Liron
> Assignee: Avia Efrat
> 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.
> Another advantage is that it's much easier to add new models that use
> {{Parameter}} by adding an extra table (many-to-many) rather than adding fk
> columns to an existing table. To that there is a simple answer: new models
> can definitely create many-to-many relationships to anything else. Using
> one-to-many for our own models doesn't preclude that. (And we can even add
> code that automatically tries to look through such many-to-many relationships
> in order to find a container.)
> 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)
