InstaGov/schema/question - Revision history

Woozle: /* History */ condensation & clarity

2013-07-14T16:32:04Z

History: condensation & clarity

← Older revision		Revision as of 16:32, 14 July 2013
Line 11:		Line 11:
	* '''2013-01-07''' Added UNIQUE KEY for Summary		* '''2013-01-07''' Added UNIQUE KEY for Summary
	* '''2013-07-14''' Revising to use {{l/pferret}}		* '''2013-07-14''' Revising to use {{l/pferret}}
	** '''Summary''' ~~field is now in {{l/pferret/sql\|post}}~~		** Removing fields duplicated in parent tables: '''Summary''', '''Page''' ({{l/pferret/sql\|post}}), '''WhenCreated''', '''WhoCreated''', '''WhenEdited''', '''WhoEdited''', '''QtyEdits''' ({{l/pferret/sql\|atom}})
	** Removing fields: '''Page''' ({{l/pferret/sql\|post}}), '''WhenCreated''', '''WhoCreated''', '''WhenEdited''', '''WhoEdited''', '''QtyEdits''' ({{l/pferret/sql\|atom}})		** Alternatively, we could have eliminated this table altogether and used the {{l/pferret/sql\|post}} table instead by adding a "class" field (to distinguish between "questions" and other types of posts), since this record now adds no other information, but we may later want to add some fields specific to the "question" class... and so far none of the other post-derivatives are capable of being this stripped-down, so the "class" field would be redundant for them.
	** Alternatively, we could have ~~just~~ used the ~~'''~~post~~'''~~ table ~~and added~~ a "class" field, since this record now adds no other information, but we may later want to add some... and so far none of the other post-derivatives are capable of being this stripped-down, so the "class" field would be redundant for them.
	==SQL==		==SQL==
	<mysql>CREATE TABLE `question` (		<mysql>CREATE TABLE `question` (

Woozle: stripped down to almost nothing so we can use PostFerret

2013-07-14T16:29:39Z

stripped down to almost nothing so we can use PostFerret

← Older revision		Revision as of 16:29, 14 July 2013
Line 10:		Line 10:
	* '''2013-01-03''' changed WhoCreated and WhoEdited from string to integer		* '''2013-01-03''' changed WhoCreated and WhoEdited from string to integer
	* '''2013-01-07''' Added UNIQUE KEY for Summary		* '''2013-01-07''' Added UNIQUE KEY for Summary
			* '''2013-07-14''' Revising to use {{l/pferret}}
			** '''Summary''' field is now in {{l/pferret/sql\|post}}
			** Removing fields: '''Page''' ({{l/pferret/sql\|post}}), '''WhenCreated''', '''WhoCreated''', '''WhenEdited''', '''WhoEdited''', '''QtyEdits''' ({{l/pferret/sql\|atom}})
			** Alternatively, we could have just used the '''post''' table and added a "class" field, since this record now adds no other information, but we may later want to add some... and so far none of the other post-derivatives are capable of being this stripped-down, so the "class" field would be redundant for them.
	==SQL==		==SQL==
			<mysql>CREATE TABLE `question` (
			`ID_Post` INT NOT NULL COMMENT "post.ID for content",
			PRIMARY KEY(`ID_Post`)
			)
			ENGINE = MYISAM;</mysql>
			==Obsolete==
	<mysql>CREATE TABLE `question` (		<mysql>CREATE TABLE `question` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID` INT NOT NULL AUTO_INCREMENT,

Woozle: Summary must be unique

2013-01-08T02:29:49Z

Summary must be unique

← Older revision		Revision as of 02:29, 8 January 2013
Line 9:		Line 9:
	* '''2012-12-28''' Removing *_Text; adding Summary, WhoCreated		* '''2012-12-28''' Removing *_Text; adding Summary, WhoCreated
	* '''2013-01-03''' changed WhoCreated and WhoEdited from string to integer		* '''2013-01-03''' changed WhoCreated and WhoEdited from string to integer
			* '''2013-01-07''' Added UNIQUE KEY for Summary
	==SQL==		==SQL==
	<mysql>CREATE TABLE `question` (		<mysql>CREATE TABLE `question` (
Line 19:		Line 20:
	`WhoEdited` INT DEFAULT NULL COMMENT "ID of user who last edited the question",		`WhoEdited` INT DEFAULT NULL COMMENT "ID of user who last edited the question",
	`QtyEdits` INT DEFAULT NULL COMMENT "number of times this question has been edited",		`QtyEdits` INT DEFAULT NULL COMMENT "number of times this question has been edited",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID`),
			UNIQUE KEY `content` (`Summary`)
	)		)
	ENGINE = MYISAM;</mysql>		ENGINE = MYISAM;</mysql>

Woozle: using new terms template

2013-01-06T16:58:35Z

using new terms template

← Older revision		Revision as of 16:58, 6 January 2013
Line 1:		Line 1:
	==About==		==About==
	* '''Purpose''': implements {{~~instagov\|concepts~~\|question}}s		* '''Purpose''': implements {{igov/term\|question}}s
	* '''Notes''':		* '''Notes''':
	** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.		** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.

Woozle: changing user fields to INT

2013-01-03T14:23:04Z

changing user fields to INT

← Older revision		Revision as of 14:23, 3 January 2013
Line 8:		Line 8:
	===History===		===History===
	* '''2012-12-28''' Removing *_Text; adding Summary, WhoCreated		* '''2012-12-28''' Removing *_Text; adding Summary, WhoCreated
			* '''2013-01-03''' changed WhoCreated and WhoEdited from string to integer
	==SQL==		==SQL==
	<mysql>CREATE TABLE `question` (		<mysql>CREATE TABLE `question` (
Line 14:		Line 15:
	`Page` VARCHAR(127) DEFAULT NULL COMMENT "optional wiki page with more information",		`Page` VARCHAR(127) DEFAULT NULL COMMENT "optional wiki page with more information",
	`WhenCreated` DATETIME NOT NULL COMMENT "when this question was entered",		`WhenCreated` DATETIME NOT NULL COMMENT "when this question was entered",
	`WhoCreated` ~~VARCHAR(127)~~ NOT NULL COMMENT "~~username~~ of user who added the question",		`WhoCreated` INT NOT NULL COMMENT "ID of user who added the question",
	`WhenEdited` DATETIME DEFAULT NULL COMMENT "when this question was last edited",		`WhenEdited` DATETIME DEFAULT NULL COMMENT "when this question was last edited",
	`WhoEdited` ~~VARCHAR(127)~~ DEFAULT NULL COMMENT "~~username~~ of user who last edited the question",		`WhoEdited` INT DEFAULT NULL COMMENT "ID of user who last edited the question",
	`QtyEdits` INT DEFAULT NULL COMMENT "number of times this question has been edited",		`QtyEdits` INT DEFAULT NULL COMMENT "number of times this question has been edited",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID`)
	)		)
	ENGINE = MYISAM;</mysql>		ENGINE = MYISAM;</mysql>

Woozle: extracted obsolete notes

2013-01-02T22:39:52Z

extracted obsolete notes

← Older revision		Revision as of 22:39, 2 January 2013
Line 4:		Line 4:
	** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.		** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.
	** Not sure if we'll actually need Pos/Neg_Text; it may be just a frill.		** Not sure if we'll actually need Pos/Neg_Text; it may be just a frill.
	** '''2011-05-02''' ~~This entire table may be redundant. Current thinking:~~		** '''2011-05-02''' Makes no sense to have Pos/Neg Text; that's an Answer thing. (See [[InstaGov/SMW/questions]] for obsolete notes.)
	*** Each question is a wiki page, marked with a predetermined category.
	*** This makes the list of questions queryable through the category table.
	*** Use [[W3TPL]] to define display text, using <let name=text>text to display</let>.
	*** Maybe we need a way for W3TPL to store <let> data, to make it more searchable -- but that can happen later.
	*** (Or maybe, given the simplicity of Question data, we just use <noinclude> to delineate text which should not be shown in question lists. For now, sticking with W3TPL.)
	~~***~~ Makes no sense to have Pos/Neg Text; that's an Answer thing.
	** '''2012-12-28''' Making the structure dependent on wiki pages increases platform-dependency and CPU overhead. Keep the table, make wiki page optional (it should default, at page creation time, to a calculated name which can be updated if the page is moved). We will probably need a log of edits to Answers. In fact, let's do a [[../edit_log\|general log]].		** '''2012-12-28''' Making the structure dependent on wiki pages increases platform-dependency and CPU overhead. Keep the table, make wiki page optional (it should default, at page creation time, to a calculated name which can be updated if the page is moved). We will probably need a log of edits to Answers. In fact, let's do a [[../edit_log\|general log]].
	===History===		===History===

Woozle: link to concept page

2012-12-30T16:23:29Z

link to concept page

← Older revision		Revision as of 16:23, 30 December 2012
Line 1:		Line 1:
	==About==		==About==
			* '''Purpose''': implements {{instagov\|concepts\|question}}s
	* '''Notes''':		* '''Notes''':
	** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.		** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.

Woozle: one more edit-tracker

2012-12-29T02:59:05Z

one more edit-tracker

← Older revision		Revision as of 02:59, 29 December 2012
Line 22:		Line 22:
	`WhenEdited` DATETIME DEFAULT NULL COMMENT "when this question was last edited",		`WhenEdited` DATETIME DEFAULT NULL COMMENT "when this question was last edited",
	`WhoEdited` VARCHAR(127) DEFAULT NULL COMMENT "username of user who last edited the question",		`WhoEdited` VARCHAR(127) DEFAULT NULL COMMENT "username of user who last edited the question",
			`QtyEdits` INT DEFAULT NULL COMMENT "number of times this question has been edited",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID`)
	)		)
	ENGINE = MYISAM;</mysql>		ENGINE = MYISAM;</mysql>

Woozle: removing unneeded fields, adding a couple more for edit-tracking purposes

2012-12-29T02:58:18Z

removing unneeded fields, adding a couple more for edit-tracking purposes

← Older revision		Revision as of 02:58, 29 December 2012
Line 10:		Line 10:
	*** (Or maybe, given the simplicity of Question data, we just use <noinclude> to delineate text which should not be shown in question lists. For now, sticking with W3TPL.)		*** (Or maybe, given the simplicity of Question data, we just use <noinclude> to delineate text which should not be shown in question lists. For now, sticking with W3TPL.)
	*** Makes no sense to have Pos/Neg Text; that's an Answer thing.		*** Makes no sense to have Pos/Neg Text; that's an Answer thing.
			** '''2012-12-28''' Making the structure dependent on wiki pages increases platform-dependency and CPU overhead. Keep the table, make wiki page optional (it should default, at page creation time, to a calculated name which can be updated if the page is moved). We will probably need a log of edits to Answers. In fact, let's do a [[../edit_log\|general log]].
			===History===
			* '''2012-12-28''' Removing *_Text; adding Summary, WhoCreated
	==SQL==		==SQL==
	~~<section begin=sql />~~<mysql>CREATE TABLE `question` (		<mysql>CREATE TABLE `question` (
	`ID` INT NOT NULL AUTO_INCREMENT,		`ID` INT NOT NULL AUTO_INCREMENT,
	`Page` ~~varchar~~(127) COMMENT "wiki page ~~describing question~~",		`Summary` VARCHAR(255) NOT NULL COMMENT "short description of question",
	`WhenCreated` DATETIME NOT NULL COMMENT "when this question was entered",		`Page` VARCHAR(127) DEFAULT NULL COMMENT "optional wiki page with more information",
	`~~Pos_Text~~` VARCHAR(63) ~~DEFAULT~~ NULL COMMENT "~~optional: default text to show at the 'yes' end~~ of the ~~scale~~",		`WhenCreated` DATETIME NOT NULL COMMENT "when this question was entered",
	`~~Neg_Text~~` VARCHAR(63) DEFAULT NULL COMMENT "~~optional: default text to show at the 'no' end~~ of the ~~scale~~",		`WhoCreated` VARCHAR(127) NOT NULL COMMENT "username of user who added the question",
			`WhenEdited` DATETIME DEFAULT NULL COMMENT "when this question was last edited",
			`WhoEdited` VARCHAR(127) DEFAULT NULL COMMENT "username of user who last edited the question",
	PRIMARY KEY(`ID`)		PRIMARY KEY(`ID`)
	)		)
	ENGINE = MYISAM;</mysql>		ENGINE = MYISAM;</mysql>
	~~<section end=sql />~~

Woozle: tentatively, this table is redundant

2011-05-03T02:06:31Z

tentatively, this table is redundant

← Older revision		Revision as of 02:06, 3 May 2011
Line 3:		Line 3:
	** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.		** I originally had a "WhenExpires" field as a way of making a decision at a specific time, but I decided that this belongs in a separate table (something like "decision point"). Timetable functionality feels "tacked-on", and putting it in a separate table allows keeping that feature from becoming entangled with basic voting. We might want to be able to implement, say, more than one decision-point per question.
	** Not sure if we'll actually need Pos/Neg_Text; it may be just a frill.		** Not sure if we'll actually need Pos/Neg_Text; it may be just a frill.
			** '''2011-05-02''' This entire table may be redundant. Current thinking:
			*** Each question is a wiki page, marked with a predetermined category.
			*** This makes the list of questions queryable through the category table.
			*** Use [[W3TPL]] to define display text, using <let name=text>text to display</let>.
			*** Maybe we need a way for W3TPL to store <let> data, to make it more searchable -- but that can happen later.
			*** (Or maybe, given the simplicity of Question data, we just use <noinclude> to delineate text which should not be shown in question lists. For now, sticking with W3TPL.)
			*** Makes no sense to have Pos/Neg Text; that's an Answer thing.
	==SQL==		==SQL==
	<section begin=sql /><mysql>CREATE TABLE `question` (		<section begin=sql /><mysql>CREATE TABLE `question` (