Hello,
I would like to propose a new direction for jyve2.0. I would
appreciate your input. This note's a bit long, but hopefully, it
makes sense.
I would like to change the following :
1. the hierarchal data flow to be completely user/project defined.
2. allow jyve to work with multiple dbases at the same time
e.g. one database might for FAQs and another for
internal helpcenter.
Right now the data topology is
projects -> FAQs -> topics -> questions -> answers
However for some cases, you might want a very flat system:
questions-> answers
or
questions -> answers -> reviews
The solution outlined below actually makes a lot of the complexity
of the code base go away. And the same template can be used regardless
of the topology. Let's start with the new database schema.
Here's the schema for hierarchal/threaded data segment management (HDSM)
(If you want one database to keep track of multiple HDSM's, then
we would need to add one more table):
CREATE TABLE DataSegment
(
id SERIAL, // auto increment primary key
pid int NOT NULL default 0, // parent id, 0 is top level
value text NOT NULL,
statusID int4 NOT NULL DEFAULT 1,
visitorId int4 NOT NULL DEFAULT 1,
displayOrder int DEFAULT 0,
deleted char NOT NULL DEFAULT 'N',
deletedBy integer,
modifiedBy integer,
modifedDate timestamp default 'now',
released char NOT NULL DEFAULT 'N',
releasedBy integer,
releasedDate timestamp default 'now',
depth int2, // system assigned
// = parent's depth + 1
// best implemented as a trigger
// will have a default implementation for
// dbase's that don't provide that functionality
PRIMARY KEY (id)
);
create unique index answer_idx1 on answer (id, pid);
create index answer_idx2 on answer (pid);
I removed saveType. Why not always use html ? Use <pre> & </pre> for
plain text. statusID is an optional fkey into a status table (not shown)
CREATE TABLE depth;
(
id SERIAL,
label varchar(80),
depth int,
PRIMARY KEY (id)
);
The depth table allows for easy selects of the data base. I figure
that viewing the information will be done much more than adding/updating.
A couple of good things happen now:
1. Moving around items is easy (haven't thought about the GUI side yet)
all you do is reassign the pid, (the children move with it). This
is on the TODO list for jyve.
2. There's only one table to worry about. That means adding new
layers is easy and don't require a massive rewrite of the code base.
3. There's a whole bunch of code reuse. No longer do you need
actions like AddQuestion, AddAnswer, ReleaseX, ReleaseY, etc.
You have an AddAction, ReleaseAction, DeleteAction, UpdateAction.
Templates can be reused as well as long as we push in the right
information into the context.
4. Clients can define the data flow how they want to.
jyve would actually be a specific instance of using the HDSM system:
Jyve
depth table:
PROJECTS 1
FAQS 2
TOPICS 3
QUESTIONS 4
ANSERS 5
(note that we could stuff other localization information into
this table as well)
The negative side of all this, is that we would have to write a
utility to reformat the data from the old system to the new system.
let me know what you think,
mike
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
