Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] technical details, plan, re: synthesis

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org
  • Subject: Re: [pcplantdb] technical details, plan, re: synthesis
  • Date: Tue, 3 Aug 2004 22:36:53 -0500

Richard Morris writes:
> Chad Knepp wrote:
> > Lawrence F. London, Jr. writes:
> > > If it is done on ibiblio I can be counted on to help out in a
> > > variety of ways for the long haul. I plan to focus more of my
> > > attention on HG than on any other web projects I work on, now or
> > > later.
> >
> > I have a high degree of confidence that ibiblio will be able to
> > provide what we need regarding a zope platform, even if it isn't right
> > away. We also have the expertise between us to do it ourselves or
> > help them do it for us. Zope really is common/popular enough to be
> > available almost everywhere. I am a little surprised that they don't
> > have an install there already, but it's no big deal. Anyway, I don't
> > think that the fact that ibiblio doesn't already have Zope should be a
> > big factor in deciding whether to go the Zope route or the Eden/MySQL
> > route.
> >
> I am very strongly in favor of a system eventually on ibiblio,
> for a number of reasons.
> 1) There are some great datasets already there namely
> permaculture mailing list
> pc wiki
> lots more lawrence has tucked away there
> 2) Connections with the wider community
> For this to work were are going to need more datasets
> from other permaculture praticioners. Theres a phrase
> over here "its not what you know its who you know"
> and the chap with the greatest connections in our group
> is Lawerence.
> 3) No long term maintanace at the sysadmin level. No long term
> server costs, high bandwidth, and a host which will
> be there for a very long time to come. Suportive sysadmins.

I feel much the same actually.

> I'm fairly agnostic as to zope, I'm happy to go with it,
> but there are many other systems which could do it as well.
> For instance perl has objects good DB connectivity and
> a vast library.

I'm mostly zope agnostic (yet), but I'm definitely pro python. Perl
objects are an abomination and an assorted set of other unutterable
curses. Java has a great OO methodology but has really weak system
level access. If you like and know Java, you practically already know
python. You really gotta look into it... it should be a snap for ya.

> I've also developed a proof of concept database system on ibiblio
> at
> http://www.ibiblio.org/pfaf/pcplantdb/index.php
> it look terible and does not have google type search but it does
> illustrate many of the features we need:
> Allows additions of information to db
> Extensible, very easy to add a new field.
> Handles other objects as well as plants.
> Beginings of support for users with varying
> levels of permision.
> Allows a strong atribution model. Footnotes are used
> to indicate who wrote what. Contributions can be woven into the
>
> different sections in the main text.
> XML output.
> Fairly well documented code and table structure. Uses a javadoc
> type
> system to make the tables self documenting.

Wow, you sure have been busy! Actually your *keywords* are a simple
controlled vocabulary, and the ability to do common name, latin name,
and keywords makes it pretty darn effective and very google-like.
Allowing collaboration puts it past Eden. If you are going to
continue development you might want to limit output of queries. I
searched for 'moist' and got a page over 1 Meg long.

> The question which has been coming up in my mind reciently is what are
> the objects? What are the initial thoughts as to what objects
> are used to represent the data.
>
> We could have:
> users - holds data about a user
> things - data about a thing (plant, guild, keylines, ...)
> plants - sub class of thing plant specific info
> section - a specific section of information about a thing
> keyword - a key word about the plant or thing
> relationships - a link between two things
> contribution - an individual contribution by an particular user about
> a
> thing.
> resource - some other resources like photos, videos mp3's.
>
> I think we need to have a clear idea about the object/data structure so
> that we can ensure that the platform we choose can suport our needs.
>
> Do we need
> sub-classing of objects?
> encapsulation - tying methods and data together?
> extensible objects?
>
> I'm not 100% convinced that objects are essential.
> A RDBM scheme can handle most of our needs.
> Its fairly straightforward to go from an database record to an object.

I'm willing to talk about this more for a variety of reasons. Very
high on my list is that ZODB does not have an effective query
methodology. From a slashdot user:

The main practical difference between ODBMS and RDBMS is that ODBMS
is good for object persistence, not for querying. Despite indexing,
arbitrary queries (ad-hoc, based on partially know structured
context) in Zope are very weak (and they will be always weak until
ZODB will become a real DBMS project). To make power queries I need
some algebra (like relational). Object model doesn't have
such.

One of our primary functions will be data queries. An RDBMS is
currently more of the right tool for that job. There are all sorts of
tradeoffs and kludges though when you mix good OO and an RDBMS.
Anyway, I disagree with some of your arguments, but not with the
outcome. I don't feel set on a particular platform yet and I/we need
to make a CONCRETE decision by this weekend. I will continue learing
the Zope platform and be prepared to go either direction by next week
but I would like to re-open the discussion.

BTW. Zcatalog and it's Catalog package is the way to have some sort
of easier querying, not IndexedCatalog. IndexedCatalog is basically a
project that died a year ago in beta. Catalog should do everything we
need. Before I started to look more closely at Zcatalog I had pretty
much schemed up a plan to re-implement what Catalog actually
does... whew.

--
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'




Archive powered by MHonArc 2.6.24.

Top of Page