CUBA-KEY / class confusion

[simphony]

CUBA-KEY / class confusion

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 27, 2019, 09:08

We need then to think about how can classes be created using enums (CUBA) instead of classes.

By Yoav Nahshon on 2019-09-27T07:08:35 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 26, 2019, 19:36

would classes also work in other languages? if no, we only use CUBA in both cases, this is the reason we used it in the first place by the way. @yoavnash would this be a good option?

a bit more coding, but more unified. opinion?

I guess we can also pass an object and it will be like a class (a bit rusty programming lately, so probably I am talking nonsense!)

By Adham Hashibon on 2019-09-26T17:47:24 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 26, 2019, 16:53

For the unification, I suggest we don't use at all the CUBA keys, but only the classes - we already use them for creating objects (e.g., a = cuds.classes.Atom())

By Yoav Nahshon on 2019-09-26T14:53:42 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 26, 2019, 14:43

I agree we should unify this.

Concerning the dictionaries, we could also use only one file to store all the information:

{
    relation1: {
        parents: [first_direct_parent_of_1, second_direct_parent_of_1, ...], # multiple inheritance
        children: [first_direct_child_of_1, second_direct_child_of_1, ...],
        inverse: inverse_of_1
    },
    class2: {
        parents: [first_direct_parent_of_2, second_direct_parent_of_2, ...], # multiple inheritance
        children: [first_direct_child_of_2, second_direct_child_of_2, ...]
        # inverse is undefined
    }
}

By Yoav Nahshon on 2019-09-26T12:44:53 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 13, 2019, 11:15

I think we use CUBA keys for all, but then we need some sort of mapping for the inverse and the inheritance in relationships.

This might also simplify the class generator, since now it requires 2 different templates (one for entities and one for relationships), and reduce the amount of files created.

Option 1:

Create dictionaries (or another datastructure) to store the information in the class generator:

For inverses:

{
 relation1: inverse_of_1,
 relation2: inverse_of_2,
}

For inheritance:

{
 relation1: direct_parent_of_1,
 relation2: direct_parent_of_2,
} // This would require multiple queries

or

{
 relation1: {ancestor_1_of_1, ancestor_2_of_1, ...},
 relation2: {ancestor_1_of_2, ancestor_2_of_2, ...},
}  // More efficient for queries, requires more space (probably insignificant)

By Pablo de Andres on 2019-09-13T09:15:19 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Aug 22, 2019, 14:07

changed the description

By Matthias Urban on 2019-08-22T12:07:35 (imported from GitLab project)

[pablo-de-andres]

In GitLab by @urbanmatthias on Sep 27, 2019, 11:33

Maybe it is easiest to set CUBA("CITIZEN") == cuds.classes.Citizen.

That way we can also create classes using the cuba key:

c = CUBA("CITIZEN")(*args, **kwargs)

[pablo-de-andres]

In GitLab by @yoavnash on Sep 27, 2019, 11:33

Classes exist in almost every language. Therefore it might make sense to use classes.

This relates also to the question of what is exactly the purpose of CUDS in osp-core. We need to clarify this first. See issue #85.

Additionally, it might seem a bit artificial if we create objects like so:

c = cuds.CUBA.create(CUBA.Atom)

or

c = CUBA("CITIZEN")(name="Peter")

@ahashibon @pablo-de-andres

[pablo-de-andres]

In GitLab by @yoavnash on Sep 27, 2019, 11:43

By @pablo-de-andres:

So when you want to filter by tzpe (i.e. CUBA type), you'd also use the class? The we sould rename the parameter

# Like this?
a.get(cuba_key=cuds.classes.Position) 

[pablo-de-andres]

In GitLab by @yoavnash on Sep 27, 2019, 11:43

Yes - it's very confusing

[pablo-de-andres]

In GitLab by @urbanmatthias on Oct 9, 2019, 14:21

From a user's point of view it might the best if the following is possible:

from osp import CUBA
a1 = CUBA.ATOM(*args, **kwargs)  # not sure about all caps
# or if we only have the string
a2 = CUBA("ATOM")(*args, **kwargs)

a1.get(cuba_key=CUBA.QUARK)
a1.get(rel=CUBA.HAS_PART)

That means CUBA.ATOM is class.

Additionally, each class could have class variables to store all ancestors and predecessors.
This might then replace the RelationshipTree, which would be obsolete in case of multi-inheritance (#91).

See also #92 #86

[pablo-de-andres]

In GitLab by @ahashibon on Oct 9, 2019, 16:44

or simply we do

a.get(entity=cuds.Position())

or

a.get(entity=cuds.Position)

which means, we use the ontology term for any thing, i.e., the entity.

[pablo-de-andres]

In GitLab by @urbanmatthias on Oct 10, 2019, 08:09

But entities also include relationsships and values, which are (right now) not allowed arguments.

(On the other hand, the same holds for cuba_key)

[pablo-de-andres]

In GitLab by @yoavnash on Oct 23, 2019, 16:18

It would be nice as well to create an object that is initially associated with a specific session. See #122.

[pablo-de-andres]

In GitLab by @yoavnash on Oct 25, 2019, 13:43

Relates to #122

[pablo-de-andres]

In GitLab by @urbanmatthias on Nov 11, 2019, 14:09

closed