View dependency - Githubissues

zacharias2k commented 11 years ago

This is directly linked with #226 and #223, but adresses a more general aspect. @abroxos and i discussed a bit what should be loaded with a view. Several cases:

view A linked to view B.
view A is of type edges, view B owns their nodes
view A is of type nodes, view B of type edge, consisting of nodes from view A
view A is of type system, view B of type X owned by systems in view A

Question: When defining only view A in the module, should view B be loaded too? Or limit the objects loaded to the ones defined in the view directly (that means, that in each of this cases both views A and B have to be defined to get full access).

@chmuibk , @christianurich your opinion?

christianurich commented 11 years ago

Should be straight forward. It is just loaded what is defined in the constructor/init.

e.g.

View House

floorspace
stuff
otherstuff
linkToHousehold

View Household

size
stuff
otherstuff
linktoPerson

View Person

age

e.g.

init

View (house, READ, DM::COMPONENT) //Geometry is not loaded the house is accessed as component
 - getAttribute(floorspace)
 - getAttribute(linkToHousehold) or better getLink(linkToHousehold) //load households linked to house. The attributes that are loaded are defined in the View section Household

View (Household, READ) //Person are not loaded
 - getAttribute(size)

 run

if someone wants to do

Household.getLinkedPerson() //Not allowed and should throw error

other example

e.g.

init

View (house, READ, DM::FACE) //Geometry is loaded since it is loaded as face (but just the geometry e.g. nodes not the attributes )
 - getAttribute(linkToParcel) 

View(Parcel, READ, DM::FACE)

run

house.getNodes()
house.getParcel().getNodes()

abroxos commented 11 years ago

According to the question of Markus this would mean: "Views A and B have to be defined to get full access)". Am i right ?

2013/9/19 Christian Urich notifications@github.com

Should be straight forward. It is just loaded what is defined in the constructor/init.

e.g.

View House

floorspace

stuff

otherstuff

linkToHousehold

View Household

size

stuff

otherstuff

linktoPerson

View Person

age

e.g.

init

View (house, READ, DM::COMPONENT) //Geometry is not loaded the house is accessed as component

getAttribute(floorspace)

getAttribute(linkToHousehold) or better getLink(linkToHousehold) //load households linked to house. The attributes that are loaded are defined in the View section Household

View (Household, READ) //Person are not loaded

getAttribute(size)

run

if someone wants to do

Household.getLinkedPerson() //Not allowed and should throw error

other example

e.g.

init

View (house, READ, DM::FACE) //Geometry is loaded since it is loaded as face (but just the geometry e.g. nodes not the attributes )

getAttribute(linkToParcel) or better getLink(linkToHousehold) //load households linked to house. The attributes

View(Parcel, READ, DM::FACE)

run

house.getNodes() house.getParcel().getNodes()

— Reply to this email directly or view it on GitHubhttps://github.com/iut-ibk/DynaMind-ToolBox/issues/228#issuecomment-24713488 .

MSc Michael Mair IUT Umwelttechnik - Institut für Infrastruktur Universität Innsbruck A-6020 Innsbruck; Technikerstrasse 13

Tel: +43 (0) 512 507 6929 M: michael.mair@uibk.ac.at W: http://umwelttechnik.uibk.ac.at W: http://michaelmair.eu

christianurich commented 11 years ago

yes

christianurich commented 11 years ago

This gives us full information about what the module really wants to do and access. This worked for my module design quite well. Is this effecting your work?

abroxos commented 11 years ago

Everything is ok. We just wanted to be sure that we are meaning the same. And yes, we did. :-)

2013/9/19 Christian Urich notifications@github.com

This gives us full information about what the module really wants to do and access. This worked for my module design quite well. Is this effecting your work?

— Reply to this email directly or view it on GitHubhttps://github.com/iut-ibk/DynaMind-ToolBox/issues/228#issuecomment-24720778 .

MSc Michael Mair IUT Umwelttechnik - Institut für Infrastruktur Universität Innsbruck A-6020 Innsbruck; Technikerstrasse 13

Tel: +43 (0) 512 507 6929 M: michael.mair@uibk.ac.at W: http://umwelttechnik.uibk.ac.at W: http://michaelmair.eu

zacharias2k commented 11 years ago

Perfectly, that's really good news.

One last question:

View (house, READ, DM::COMPONENT) //Geometry is not loaded the house is accessed as component

In this case component is a face, but it is treated as component, meaning that nodes are not touched - is that correct?

christianurich commented 11 years ago

exactly and therefore don't need to be loaded.

just to clarify

View (house, READ, DM::COMPONENT) // treats house as component View (house, READ, DM::FACE) treats house as face and therefore nodes are loaded but just read access is needed View (house, MODIFY, DM::FACE) same as above + write access to the nodes View (house, WRITE, DM::FACE) creates new houses

zacharias2k commented 11 years ago

View (house, READ, DM::FACE) treats house as face and therefore nodes are loaded but just read access is needed

wait, you mean the view containing the nodes doesn't have to be defined explicit? Like

View(house-nodes, READ, DM::NODE)

thus, defining View (house, MODIFY, DM::FACE) enables you to modify e.g. the node coordinates?

christianurich commented 11 years ago

no that's defined in the view constructor.

Read in the constructor does not mean the whole view is read. The attribute definition can still contain a write e.g. following example is valid.

house = View (house, READ, DM::FACE) // defines access to geometry house.addAttribute("mything") // still adds an attribute

zacharias2k commented 11 years ago

View (house, READ, DM::FACE) treats house as face and therefore nodes are loaded but just read access is needed

I'm talking about the nodes linked to the face. e.g.

View houses(house, READ, DM::FACE);

components = getData("")->getAllComponentsOfView(houses);
nodes = components[0]->getNodes();

the question is, can i access getNodes without defining

View housenodes(housenodes, READ, DM::NODES);

or should it bring an error, because i didn't declared the nodes in a specific view to be accessed.

The whole thread is about loading things that are not explicitly defined, but might be loaded, it's not about attributes, nor about coordinates, even geometric-access rights shouldn't play a part in this specific question. That's why i wrote the 4 cases on top (AFAIK there are only 4).

christianurich commented 11 years ago

yeah that is what I mean with View houses(house, READ, DM::FACE) loads the whole geometry including nodes.

so getNodes works and gives me the actual node pointers.

no need for View housenodes(housenodes, READ, DM::NODES);

zacharias2k commented 11 years ago

ok, because

abroxos commented 6 hours ago According to the question of Markus this would mean: "Views A and B have to be defined to get full access)". Am i right ?

christianurich commented 6 hours ago yes

would have meant the opposite. But anyway ty for the time being.

christianurich commented 11 years ago

No because nodes don't need to be in a view so there is no view B for the geometry

since I also don't write following view definition to create a face

DM::VIEW("HOUSE", FACE, WRITE) ~~DM::VIEW("", NODE, WRITE)~~

Follwing is perfectly valid and just defines the geometry

n1 = sys.addNode(0,0,0) //No View

sys.addFace(vector(n1),house)

abroxos commented 11 years ago

Just a short list of use cases --- if some case is missing please add them: Y=yes N=no

View type Nodes: also load edges geometry (method Node::getAllEdges() ) ? Y View type Face: also load nodes geometry (method Face::getNodes() ) ? Y View type Edges: also load nodes geometry (method Edges::getStartPoint() and Edges::getEndPoint() ) ? Y View type Component: load nothing there is no geometry ? Y View type System: ? Completely unclear for me. Link Attribute: also load geometry within all linked Views ? Y

In all cases if someone wants to access attributes they have to be explicitly defined in the view.

2013/9/19 zacharias2k notifications@github.com

Well, that's a shame. Because that will most definitly block efficient useage of filters (internal core/sql issue).

I would really like to see the nodes being defined in a separate view (1), or defined with the view (2).

one line of work for the module programmer, but the core can optimize a lot and also prevents cascade loading from db, which will cause a serious performance issue

basicall usage as now, but using dataviewer.getallcomponents would return nodes and faces, sys.getcompsofview could stay the way it is, returning only faces (pure backwards compatibility issue) - although this would be somehow inconsistent

Note: Both could be implemented (AFAIK) 100% backwards compatible. Note 2: It makes no difference if READ or WRITE is specified - for the core itself both result in the same.

— Reply to this email directly or view it on GitHubhttps://github.com/iut-ibk/DynaMind-ToolBox/issues/228#issuecomment-24739961 .

MSc Michael Mair IUT Umwelttechnik - Institut für Infrastruktur Universität Innsbruck A-6020 Innsbruck; Technikerstrasse 13

Tel: +43 (0) 512 507 6929 M: michael.mair@uibk.ac.at W: http://umwelttechnik.uibk.ac.at W: http://michaelmair.eu

christianurich commented 11 years ago

Just some minor comments to the list for clarification

View type Nodes: also load edges geometry (method Node::getAllEdges() ) ? Y

Not sure if this is yes in general.

Lets assume following views in the data stream

View(conduit, EDGE)
 - linkToJunction
View(junction, NODE)
 - linkToConduit

Use case 1:

View(junction, NODE, READ) // No conduit defined

junction::getAllEdges() N

Use case 2:

View(conduit, EDGE, READ) // No junction defined

n = conduit.getStartNode() n.getAllEdges() Y <- returns conduit edges connected to the node

Use case 3:

View(junction, NODE, READ) 
View(conduit, EDGE, READ)

junction.getAllEdges() N <- because not linked

Use case 4:

View(junction, NODE, READ) 
 - linkToConduit
View(conduit, EDGE, READ)

junction.getAllEdges() Y <- because linked

Use case 5:

View(junction, NODE, READ) 
View(conduit, EDGE, READ) 
- linkToJunction

junction.getAllEdges() Y <- because linked

View type Edges: also load nodes geometry (method Edges::getStartPoint() and Edges::getEndPoint() ) ? Y also loads NODE.getAllEdges (see use case above)

View type System: ? not sure either but I assume it makes sense that for a SUBSYSTEM all geometry is loaded (faces, edges, nodes)

Edit: formated for better reading :-)

zacharias2k commented 11 years ago

Regarding subsystem: I'm with you, i think it makes sense to load the whole system too. We are trying to get rid of the system as "data stream container", so we can make it some sort of more lightweight - as it will be used as subsystem only

add case 3: I think no module programmer would understand, why he can access junctions from nodes, but not vice versa. It is a missing internal linking, the data tree is broken - if we provide a method for getting edges, we should make it accessable, as all edges had been loaded (-> the data exists, it is even already cached).

If we would allow the module programmer to access the edges via nodes, we could get rid of case 5 & 6?
Thus, couldn't we get rid of the whole linking too?

To visualize the "linking", the core itself could provide the info. e.g. in the view stream gui, via internal comparison.

PS: when the post get lengthy, please add some formating, it's really hard to read

iut-ibk / DynaMind-ToolBox

View dependency #228