pcplantdb

[Richard Morris <webmaster@pfaf.org>]

Lawrence F. London, Jr. wrote:

> John Schinnerer wrote:
>
> > Aloha,
> >
> > > Can you provide a layman's explanation of ORM with MySQL and what the 
> > > default/alternative would be?
> >
> >
> >
> > > What are the advantages offered by ORM as the object-oriented approach?
I don't really know of any other aproach. There are different
ways you can do the mapping though.

> > IMO an object model for our project is much more appropriate than a 
> > relational-database model.
> >
> > Plant objects (stored in an object DB) would contain information about 
> > themselves and ways ('methods', meaning essentially bits of code) to 
> > share than information.
>
> How do those bits of code (each possibly a microcosm of other bits of code
> as with plant taxonomical data) communicate with other bits of code 
> "attached" to
> other objects, i.e. other plants, microfauna, microflora, mammals, 
> birds, reptile objects,
> guild objects, pc systems objects (i.e. landforms involving weather 
> exposure, soil, water,
> stone, wood, manade materials), water, soil, etc.

On the server they don't really need to do anything!
basically there are two tasks
        find objects with given properties
        display objects (including links to other objects)

There are design decisions needed about where the display
method fits. We can have
        display(plant)
or      plant.display()

In the former the display method and data are separate
the plant object does not know how to create the web page about it.
This makes it easier to use a variety of different
ways to display a plant. We might want to create a
PlantDisplayer class and sub classes of this handle the display,
viz htmlPlantDisplayer, xmlPlantDisplayer, touchgraphPlantDisplayer.

In the latter the plant knows how to display itself.
This can make it easier to redo the display if the underlying
data changes.

I favor the first as it will be more flexable. I think
it also goes well with model-view-controller design pattern.

I'll not talk about how to do find yet as its a much more
complicated subject.

(side note intended to confuse!
Just had to implement the observer pattern
in this an object (A) has a set of listeners (other objects
which are interested in A).
if the object is changed then it sends a message to
all its listeners saying "I have changed".
This is the way GUI's are handeled in java,
a button says "I've just been presses" to anyone
who is interested.

This could be useful for say letting someone
know if a plant they have special interest in has
been changed. Or it could be added to the Rich's mad idea
of the day list).

> > This is essentially what real-world plants do - they 'know' about 
> > themselves and communicate with other entities in a variety of ways - 
> > colors and scents to attract pollinators and/or repel predators, root 
> > exudates to attract symbiotic micro-fauna or scare off predatory 
> > micro-fauna, and so on.
>
>
> Just rambling - this is getting interesting.
>
> This may be boring to the programmers but possibly useful to other laymen.
> Trying to think of an image that describes this real world system in 
> software terms.
> I envision for the object model as a ball covered with stickum on a pole 
> in the wind
> gathering information debris. Each piece of debris can send 
> semaphore-like signals to
> other balls each with their own unique debris-array.
>
> I'm trying to relate this to a touchgraph-like display and what happens 
> when negotiating
> or navigating your way through one.

In touchgraph the map is specified by an xml file something like

<TOUCHGRAPH_LB version="1.20">
    <NODESET>

// describes an individual node in the graph
// includes a unique identifier, a lable for display and a hint
// shown when the mouse is over the node

        <NODE nodeID="Dicliptera japonica">
            <NODE_LOCATION x="0" y="0" visible="false"/>
            <NODE_LABEL label="Dicliptera japonica" shape="1"
backColor="0033cc" textColor="FFFFFF" fontSize="14"/>
            <NODE_HINT hint="Species Dicliptera japonica; " width="200"
height="-1"/>
        </NODE>

// this one includes a url

        <NODE nodeID="Acanthaceae">
            <NODE_LOCATION x="0" y="0" visible="true"/>
            <NODE_LABEL label="Acanthaceae" shape="2"
backColor="006699" textColor="FFFFFF" fontSize="14"/>
            <NODE_HINT hint="Family Acanthaceae; Acanthus family" width="200"
height="-1"/>
            <NODE_URL url="Plantae.xml" urlIsLocal="true" urlIsXML="true"/>
        </NODE>
        ..........
    </NODESET>
    <EDGESET>
        <EDGE fromID="Dicliptera" toID="Dicliptera japonica" type="2"
length="80" visible="true" color="A0A0A0"/>

        <EDGE fromID="Acanthaceae" toID="Justicia" type="2" length="80"
visible="true" color="A0A0A0"/>

        <EDGE fromID="Acanthaceae" toID="Dicliptera" type="2"
length="80" visible="true" color="A0A0A0"/>
        ............
    </EDGESET>
</TOUCHGRAPH_LB>

Basically a collection of Nodes (plants) and the links between nodes
(relationships).

Points to note:
1) The nodes and the links are held seperatly. In other words
the plant does not know about its relationship.

This is quite a subtile point which I've tried to mention before
about where do the relationship live. Basically there are two
ways of doing it. Assume we want to represent the fact that
carrots and tomatoe are compaion plants.

We can either include the relationship in the actual plant object
so we have

<node nodeID="carrot">
        <relationship toID="tomato" type="compaion plant" />
</node>

<node nodeID="tomato">
        <relationship toID="carrot" type="compaion plant" />
</node>

or we can do the touchgraph way

<node nodeID="carrot">
</node>

<node nodeID="tomato">
</node>

<edge fromID="carrot" toID="tomato" type="compaion plants"
bidirectional="true"/>

I favor the latter way, as I beleive its more maintainable
(there is only one link rather than two, easy to do in a relationalDB).



2) We now have a whole new problem xml-object mappings
or xml-relationalDB mappings. I.E. how we get from our internal
representation on the server to the xml (or html).

If we want an OO server and a relational DB we then have

xml- object - relationalDB mapping

i.e. we need to translate relational db to objects to xml.

We could of course just go
xml - relationalDB

which is what I've done with the pfaf website. And in essence is what
Eden does (it does use objects but these just have a
display method which does the RDB -> html mapping,
rather than creating a object with lots of properties, such as its
height, which could be quried as to its height).

A fancy solution is to use a native xml database (apachee
has an XIndices xml database). To produce a webpage
you can use an xml transformations (XSLT) which turn
one xml representation into another (for web pages this is html or xhtml).

3) In the touch graph application there is some other
object (not a node or a link) which does the display.

> > In a relational-DB model, plants are abstracted as tables of 
> > information 'about' plants, with columns identifying general 
> > attributes/characteristics of plants and rows containing specific 
> > information on particular plants.
> > Instead of simply asking a plant object about itself in various ways, 
> > queries have to be constructed to de-abstract the abstractions created 
> > in making the tables, in order to extract the desired information 
> > 'about' the desired plant or plants.
>
>
> Maybe this is a matter of orchestrating, coordinating massive amounts of 
> table lookups
> with one result of this process being that seemingly unrelated 
> information can be
> viewed by a user wishing to discover new and possibly previously hidden 
> relationships
> between things. Maybe you would have tables of tables as with columns of 
> attributes-as-other-tables.

You don't really have tables of tables. You can have tables
which contain keys which can be used to access other tables
and you can JOIN tables in effect creating a new table
which has elements from two other tables.

> > Either approach can be made to do what we want.
> > I think the relational databse approach will get really really nastily 
> > complex and hard to work with as we add complexity to both tables and 
> > queries.

Posibly mirrored by the number of indices
we need to create.

> > The object-oriented approach just seems way more appropriate - 
> > simpler, more like what we are trying to model.

Not always simpler. For the pfaf website
where there is basically only one page
which does any display work, and only one developer,
then going through a whole relationalDB - object
mapping is a waste
of time. Basically just fill an object with the properties
from the database and a second later
reading its properties and finish.

Where it will come into use is if we have
multiple dispaly methods, so multiple things use the same object.

It should also make the code more maintainable.
An object defines an interface which should remain
fairly consistant. So someone writing a display method
can rely on certain properties exsisting.

(Side note: in the Java world there are very
good arguments for defining objects by an Interface
specifying the public API. Instead of subclasses
extending an object they inherit the Interface
and are free to use whatever base class they choose.

interface PlantI
        int getHeight()

object PlantType1 implements PlantI
        int height
        int getHeight()
                return height
        
displayPlant(PlantI plant)
        print plant.getHeight

don't know enough about python to know if that
makes sense there.)

> > We are already a culture addicted to abstraction; I think plant 
> > objects in an OO database are less an abstraction than relational 
> > database tables full of bits of data about plants.
>
> Can you explain this a little further?
Well the notion of a plant species is an abstraction.
It represents a whole set of individual plants
which are all different in subtile ways. Their simalarities
make the plant species a (mostly) useful abstraction.

I'm sure that there is some quote out there saying
computer science is the science of constructing
useful abstractions.

        Rich
--
Plants for a Future: 7000 useful plants
Web:   http://www.pfaf.org/ same as http://www.comp.leeds.ac.uk/pfaf/
Post:  1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel:     01208 872 963 / 0845 458 4719  
Email: webmaster@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf