Closed zacharias2k closed 10 years ago
Should be straight forward. It is just loaded what is defined in the constructor/init.
e.g.
View House
View Household
View Person
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()
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
yes
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?
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
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?
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
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?
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
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).
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);
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.
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)
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
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 :-)
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).
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
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:
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?