From zman at wplug.org  Sun Jun  2 17:30:38 2002
From: zman at wplug.org (Zach Paine)
Date: Sun, 2 Jun 2002 17:30:38 -0400
Subject: [wplug-web] Meeting DB
Message-ID: <20020602213038.GA30425@wplug.org>

Hey,
	I want to re-organize the meeting DB.  Currently everything is
	kind of hapharzadly thrown into one table.  Someone decided
	along the way that we should keep track of each 'new' meeting
	info via an id, but this breaks down logistically somewhat
	because frequently, info will change for a meeting, but not an
	installfest.  Should this be a new record or a modification of
	an existing one.  Currently it seems that seperate records are
	determined by when the info changes or something.  I'd like to
	seperate the meeting info and installfest info into seperate
	tables, as well as create a new table for tutorial info.
	Obviously this would involve some re-write of the php, but
	nothing grand.  In the process, I would also like to further
	abstract some processes that are repeated over and over such as
	connecting to the DB and making certain calls.  How do you guys
	feel about all this?

	-Zach

	ps. Evan: What is the status of unstable? Are you still working
	on it?


From jeremy at gunix.net  Mon Jun  3 19:16:33 2002
From: jeremy at gunix.net (Jeremy Dinsel)
Date: Mon, 3 Jun 2002 16:16:33 -0700 (PDT)
Subject: [wplug-web] Re: Meeting DB
In-Reply-To: <200206031601.g53G1No22305@wplug.org>
Message-ID: <Pine.LNX.4.30.0206031612560.23295-100000@falken.gunix.net>

On Mon, 3 Jun 2002 wplug-web-request at wplug.org wrote:

: Date: Sun, 2 Jun 2002 17:30:38 -0400
: To: wplug-web at wplug.org
: From: Zach Paine <zman at wplug.org>
: Subject: [wplug-web] Meeting DB
: Reply-To: wplug-web at wplug.org
:
: Hey,
: 	I want to re-organize the meeting DB.  Currently everything is
: 	kind of hapharzadly thrown into one table.  Someone decided
: 	along the way that we should keep track of each 'new' meeting
: 	info via an id, but this breaks down logistically somewhat
: 	because frequently, info will change for a meeting, but not an
: 	installfest.  Should this be a new record or a modification of
: 	an existing one.  Currently it seems that seperate records are
: 	determined by when the info changes or something.  I'd like to
: 	seperate the meeting info and installfest info into seperate
: 	tables, as well as create a new table for tutorial info.
: 	Obviously this would involve some re-write of the php, but
: 	nothing grand.  In the process, I would also like to further
: 	abstract some processes that are repeated over and over such as
: 	connecting to the DB and making certain calls.  How do you guys
: 	feel about all this?

It was I who gave the meetings a unique ID as we had been *deleting*
previous meetings with each new announcement. :( When information is
updated, the records should stay the same (minus the changes)--the
unique ID should be the key that is used when updating fields. Again,
the unique ID is set when a new entry is created -- it should never
change.

I guess I'm not really seeing what the problem is. Can you give an
example?

It does not make sense to me that we'd want seperate tables for the
different meeting types.

Please keep in mind that monkeybot relies on the tables to be accessed
as they currently are. Without this ability, monkeybot cannot get the
news or the meeting information.

-j



From jeremy at gunix.net  Mon Jun  3 23:46:35 2002
From: jeremy at gunix.net (Jeremy Dinsel)
Date: Mon, 3 Jun 2002 20:46:35 -0700 (PDT)
Subject: [wplug-web] Re: Meeting DB
In-Reply-To: <200206031601.g53G1No22305@wplug.org>
Message-ID: <Pine.LNX.4.30.0206032032110.24433-100000@falken.gunix.net>

After re-reading this and describing the db directly, the problem that
zman seems to be describing is that someone put both meeting information
and installfest into seperate columns in the same table row.


mysql> describe announcements;
+----------------+---------+------+-----+---------+----------------+
| Field          | Type    | Null | Key | Default | Extra          |
+----------------+---------+------+-----+---------+----------------+
| serial         | int(11) |      | PRI | NULL    | auto_increment |
| nextmeeting    | date    | YES  |     | NULL    |                |
| nextfest       | date    | YES  |     | NULL    |                |
| nextmeetingloc | blob    | YES  |     | NULL    |                |
| nextfestloc    | blob    | YES  |     | NULL    |                |
| comments       | blob    | YES  |     | NULL    |                |
| meetingdetails | blob    | YES  |     | NULL    |                |
| festdetails    | blob    | YES  |     | NULL    |                |
+----------------+---------+------+-----+---------+----------------+
8 rows in set (0.00 sec)

While this is lame, I don't think that we need seperate tables
for the data. Rather, if something is going to be broken out, the
following should be done in my opinion:

New announcements db (holds all meeting types; meeting type signified by
the "meetingtype" field:
+----------------+---------+------+-----+---------+----------------+
| Field          | Type    | Null | Key | Default | Extra          |
+----------------+---------+------+-----+---------+----------------+
| serial         | int(11) |      | PRI | NULL    | auto_increment |
| nextmeeting    | date    | YES  |     | NULL    |                |
| nextmeetingloc | blob    | YES  |     | NULL    |                |
| comments       | blob    | YES  |     | NULL    |                |
| details        | blob    | YES  |     | NULL    |                |
| meetingtype    | int(11) |      | PRI | NULL    |                |
+----------------+---------+------+-----+---------+----------------+

Table meetingtypes:
+----------------+---------+------+-----+---------+----------------+
| Field          | Type    | Null | Key | Default | Extra          |
+----------------+---------+------+-----+---------+----------------+
| serial         | int(11) |      | PRI | 0       | auto_increment,|
|                |         |      |     |         | unique         |
| meetingtype    | varchar(16) |  |     | NULL    |                |
+----------------+---------+------+-----+---------+----------------+


Each new type would be typecast with a numerical value (serial, the
primary key) and meetingtype would hold it's english name.
Thus, to obtain the meeting types, one would join the two tables:

SELECT STRAIGHT_JOIN * FROM announcements,meetingtypes WHERE
       announcements.meetingtype=meetingtypes.serial AND
       meetingtypes.meetingtype="Install Fest" ORDER BY
       announcements.serial DESC;


or well, something similar. I don't have a test db to evaluate the sql
with right now.

This would allow us to quickly select the last (limit 1) row for any
meeting type and display it on the Meeting Info bar at wplug. It would
also allow monkeybot to do something similar (with some changes).

-j


On Mon, 3 Jun 2002 wplug-web-request at wplug.org wrote:

 Date: Sun, 2 Jun 2002 17:30:38 -0400
: To: wplug-web at wplug.org
: From: Zach Paine <zman at wplug.org>
: Subject: [wplug-web] Meeting DB
: Reply-To: wplug-web at wplug.org
:
: Hey,
: 	I want to re-organize the meeting DB.  Currently everything is
: 	kind of hapharzadly thrown into one table.  Someone decided
: 	along the way that we should keep track of each 'new' meeting
: 	info via an id, but this breaks down logistically somewhat
: 	because frequently, info will change for a meeting, but not an
: 	installfest.  Should this be a new record or a modification of
: 	an existing one.  Currently it seems that seperate records are
: 	determined by when the info changes or something.  I'd like to
: 	seperate the meeting info and installfest info into seperate
: 	tables, as well as create a new table for tutorial info.
: 	Obviously this would involve some re-write of the php, but
: 	nothing grand.  In the process, I would also like to further
: 	abstract some processes that are repeated over and over such as
: 	connecting to the DB and making certain calls.  How do you guys
: 	feel about all this?
:
: 	-Zach
:
: 	ps. Evan: What is the status of unstable? Are you still working
: 	on it?
:
:
: --__--__--
:
: _______________________________________________
: wplug-web mailing list
: wplug-web at wplug.org
: http://www.wplug.org/mailman/listinfo/wplug-web
:
:
: End of wplug-web Digest
:


--
- Jeremy Dinsel
- somewhere in the monkey house



From rdale at wplug.org  Tue Jun  4 09:52:40 2002
From: rdale at wplug.org (Robert Dale)
Date: Tue, 4 Jun 2002 09:52:40 -0400 (EDT)
Subject: [wplug-web] Meeting DB
In-Reply-To: <20020602213038.GA30425@wplug.org>
Message-ID: <Pine.LNX.4.44.0206040951290.29818-100000@penguin.wplug.org>

On Sun, 2 Jun 2002, Zach Paine wrote:

> Hey,
> 	I want to re-organize the meeting DB.  Currently everything is
> 	kind of hapharzadly thrown into one table.  Someone decided
[snip]

I heard there was a fully fleshed-out db schema at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lain/lain/docs/lain.pgsql?rev=1.4&content-type=text/vnd.viewcvs-markup

-- 
Robert Dale




From rdale at wplug.org  Tue Jun  4 09:56:02 2002
From: rdale at wplug.org (Robert Dale)
Date: Tue, 4 Jun 2002 09:56:02 -0400 (EDT)
Subject: [wplug-web] Re: Meeting DB
In-Reply-To: <Pine.LNX.4.30.0206031612560.23295-100000@falken.gunix.net>
Message-ID: <Pine.LNX.4.44.0206040955150.29818-100000@penguin.wplug.org>

On Mon, 3 Jun 2002, Jeremy Dinsel wrote:

> Please keep in mind that monkeybot relies on the tables to be accessed
> as they currently are. Without this ability, monkeybot cannot get the
> news or the meeting information.

So monkeybot is written in stone and must be obeyed?  That's rather unfortunate.

-- 
Robert Dale




From jeremy at gunix.net  Tue Jun  4 11:15:57 2002
From: jeremy at gunix.net (Jeremy Dinsel)
Date: Tue, 4 Jun 2002 08:15:57 -0700 (PDT)
Subject: [wplug-web] Re: Meeting DB
In-Reply-To: <Pine.LNX.4.44.0206040955150.29818-100000@penguin.wplug.org>
Message-ID: <Pine.LNX.4.30.0206040814160.24433-100000@falken.gunix.net>

The point is that changing the dbs doesn't only effect the web pages,
there are other places where the data is retrieved. Thus, more code will need
to be changed.

-j

On Tue, 4 Jun 2002, Robert Dale wrote:

: Date: Tue, 4 Jun 2002 09:56:02 -0400 (EDT)
: From: Robert Dale <rdale at wplug.org>
: Reply-To: wplug-web at wplug.org
: To: wplug-web at wplug.org
: Subject: Re: [wplug-web] Re: Meeting DB
:
: On Mon, 3 Jun 2002, Jeremy Dinsel wrote:
:
: > Please keep in mind that monkeybot relies on the tables to be accessed
: > as they currently are. Without this ability, monkeybot cannot get the
: > news or the meeting information.
:
: So monkeybot is written in stone and must be obeyed?  That's rather unfortunate.
:
: --
: Robert Dale
:
:
: _______________________________________________
: wplug-web mailing list
: wplug-web at wplug.org
: http://www.wplug.org/mailman/listinfo/wplug-web
:


--
- Jeremy Dinsel
- somewhere in the monkey house