Tryton Blue Print for Structuring Parties

[gsps, 2010-08-19 20:19:57]

Comments pertaining the naming ("roll-up Parties") and the perceived caveats of
"roll-up Organizations"

http://codereview.appspot.com/2001042/diff/2001/3001
File party_rollup_overview.rst (left):

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode60
party_rollup_overview.rst:60: Roll-up Parties
Proposal:
Rename 'roll-up parties' to 'complex' or 'compound' parties;
'Roll-up' seems to be relatively specific economic-jargon speech,
'complex' appears to be technically correct to me

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode141
party_rollup_overview.rst:141: another module, maybe party_relationship
explained in short above.
I disagree. We could easily avoid this by not creating a one2many relation for
an Organization's children. Rather, we could use an association table (basically
as in a many2many relation) and assign a unique id to each 'roll-up' / 'cluster'
of Organizations.
This would not break the tree-nature of the organization-graphs, as within each
cluster the path from one node to another is still uniquely defined. Evaluating
that path has to be done in python anyway, so there'd be no performance loss.
And while this does increase the complexity of the database structure and
relevant queries, it's nothing compared to creating duplicates or dummy nodes in
order to maintain the strict one2many database schema.

[udono, 2010-08-19 20:36:46]

http://codereview.appspot.com/2001042/diff/2001/3001
File party_rollup_overview.rst (left):

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode60
party_rollup_overview.rst:60: Roll-up Parties
On 2010/08/19 20:19:57, gsps wrote:
> Proposal:
> Rename 'roll-up parties' to 'complex' or 'compound' parties;
> 'Roll-up' seems to be relatively specific economic-jargon speech,
> 'complex' appears to be technically correct to me

Done.

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode141
party_rollup_overview.rst:141: another module, maybe party_relationship
explained in short above.
On 2010/08/19 20:19:57, gsps wrote:
> I disagree. We could easily avoid this by not creating a one2many relation for
> an Organization's children. Rather, we could use an association table
(basically
> as in a many2many relation) and assign a unique id to each 'roll-up' /
'cluster'
> of Organizations.

As I said, it is a design decision and not a limitation. 
You prefer a network structure. In my use case, the network pattern is not so
good, as I try to describe above. We can always add a model based on a network
pattern in a separate chapter of this document.

The result is just two modules, you can install. One for network, one for
hierachical roll-ups.

> This would not break the tree-nature of the organization-graphs, as within
each
> cluster the path from one node to another is still uniquely defined.
Evaluating
> that path has to be done in python anyway, so there'd be no performance loss.
> And while this does increase the complexity of the database structure and
> relevant queries, it's nothing compared to creating duplicates or dummy nodes
in
> order to maintain the strict one2many database schema.

In my use case I need a strict one to many from one organization to another. In
my usecase I needed always to determine a unique headquarter.

[yangoon1, 2010-08-19 20:39:12]

http://codereview.appspot.com/2001042/diff/2001/3001
File party_rollup_overview.rst (left):

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode60
party_rollup_overview.rst:60: Roll-up Parties
On 2010/08/19 20:19:57, gsps wrote:
> Proposal:
> Rename 'roll-up parties' to 'complex' or 'compound' parties;
> 'Roll-up' seems to be relatively specific economic-jargon speech,
> 'complex' appears to be technically correct to me

Roll-up in this context means the tree structure of organizations and people
adhering to them. So complex doesn't apply to this meaning IMHO.

But I would rename the header to 'Party Roll-up' line Part Type' above.

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode141
party_rollup_overview.rst:141: another module, maybe party_relationship
explained in short above.
On 2010/08/19 20:19:57, gsps wrote:
> I disagree. We could easily avoid this by not creating a one2many relation for
> an Organization's children. Rather, we could use an association table
(basically
> as in a many2many relation) and assign a unique id to each 'roll-up' /
'cluster'
> of Organizations.
> This would not break the tree-nature of the organization-graphs, as within
each
> cluster the path from one node to another is still uniquely defined.
Evaluating
> that path has to be done in python anyway, so there'd be no performance loss.
> And while this does increase the complexity of the database structure and
> relevant queries, it's nothing compared to creating duplicates or dummy nodes
in
> order to maintain the strict one2many database schema.

Good point, agreed.

[udono, 2010-08-19 21:11:31]

http://codereview.appspot.com/2001042/diff/2001/3001
File party_rollup_overview.rst (left):

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode141
party_rollup_overview.rst:141: another module, maybe party_relationship
explained in short above.
On 2010/08/19 20:39:12, yangoon wrote:
> On 2010/08/19 20:19:57, gsps wrote:
> > I disagree. We could easily avoid this by not creating a one2many relation
for
> > an Organization's children. Rather, we could use an association table
> (basically
> > as in a many2many relation) and assign a unique id to each 'roll-up' /
> 'cluster'
> > of Organizations.
> > This would not break the tree-nature of the organization-graphs, as within
> each
> > cluster the path from one node to another is still uniquely defined.

Here we need an abstract vector with the organization and the cluster to use. I
really think networks of all kind can be better described with general
relationships.

Anyway Tryton does not have a widget to show networks, for now.

[gsps, 2010-08-19 21:19:38]

http://codereview.appspot.com/2001042/diff/2001/3001
File party_rollup_overview.rst (left):

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode60
party_rollup_overview.rst:60: Roll-up Parties
On 2010/08/19 20:39:12, yangoon wrote:
> On 2010/08/19 20:19:57, gsps wrote:
> > Proposal:
> > Rename 'roll-up parties' to 'complex' or 'compound' parties;
> > 'Roll-up' seems to be relatively specific economic-jargon speech,
> > 'complex' appears to be technically correct to me
> 
> Roll-up in this context means the tree structure of organizations and people
> adhering to them. So complex doesn't apply to this meaning IMHO.
> 
> But I would rename the header to 'Party Roll-up' line Part Type' above.

Fair enough; are there any dictionaries or glossaries that give an explanation
of the term though? A quick search didn't yield any reasonable notes. I only got
the Wikipedia article addressing the 'technique used by investors'.
All I'm saying is, 'compound' is a perfectly concise and widely-known word for
what we're trying to model.
See also the Oxford Dictionary, defining it as "a thing that is composed of two
or more separate elements; a mixture".

http://codereview.appspot.com/2001042/diff/2001/3001#oldcode141
party_rollup_overview.rst:141: another module, maybe party_relationship
explained in short above.
On 2010/08/19 20:36:47, udono wrote:
> On 2010/08/19 20:19:57, gsps wrote:
> > (...)
> 
> As I said, it is a design decision and not a limitation. 
> You prefer a network structure. In my use case, the network pattern is not so
> good, as I try to describe above. We can always add a model based on a network
> pattern in a separate chapter of this document.

I was in fact talking about a tree structure as well :-)
However, what I described was creating multiple trees. So instead of creating
multiple instance of one and the same Organization, you would instead only
create a separate tree. That tree would be represented by it's edges (the
connection of one Organization to another).
Now implementing this would just so happen to require a separate table for these
"connections" - which at first glance comes close to a "network" or what you'd
expect to set up in a many2many relation. That's not quite the case though, as
the connections would still be strictly directed and we wouldn't allow cycles.
The result is multiple tree-structures, the only difference being HOW you read
and traverse the tree.
I could sketch up the database schematics if it's still unclear.

> 
> The result is just two modules, you can install. One for network, one for
> hierachical roll-ups.
> 
> > This would not break the tree-nature of the organization-graphs, ...
> 
> In my use case I need a strict one to many from one organization to another.
In
> my usecase I needed always to determine a unique headquarter.

As mentioned above, this would not break support for unique routes. For any
given organization _within a specific roll-up_ there still exists one
unmistakable headquarter / root.

Even if this really doesn't work out for your specific application, the data
structure would still be superior to a single immutable tree of organizations,
as far as I can tell.