[
https://issues.apache.org/jira/browse/ARIA-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tal Liron updated ARIA-180:
---------------------------
Description:
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.
was:
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.
> 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.
> 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)
