Thread: PGDN content information proposal
Dear All,
I would like to start a discussion regarding the content information and structure we would like to have in PGDN.
Here is the proposal:
The content in PGDN has the following:
1. Content id (of course) (sequence generated number)
2. Author (user or author id)
3. major version (numeric like 3)
4. minor version (numeric like 2
5. revision. (numeric like 5)
This makes a document version of 3.2.5
6. content applies to a PostgreSQL version. (varchar) (like “all pg versions”, “8.x”,”7.x”
7. title (varchar)
8. A short description (varchar) (this would be the content introduction)
9. status (varchar) (E for editing for published, R for rejected)
10. the actual content or the story
11. date created
12. date updated
13. content type (like how-to, article, tutorial, etc ..)
Do we need more information about a PGDN content? Please let me know what you think.
Ps. the category and the keywords of the content are saved elsewhere.
Regards,
Gevik.
On Thu, 30 Jun 2005, Gevik Babakhani wrote:
> Dear All,
>
>
>
> I would like to start a discussion regarding the content information and
> structure we would like to have in PGDN.
>
> Here is the proposal:
>
>
>
> The content in PGDN has the following:
>
> 1. Content id (of course) (sequence generated number)
we need two id's once we allow updating document. One is a pub_id -
publicly accessed persistent id and msg_id - internal id.
>
> 2. Author (user or author id)
>
>
>
> 3. major version (numeric like 3)
>
> 4. minor version (numeric like 2
>
> 5. revision. (numeric like 5)
>
> This makes a document version of 3.2.5
>
>
>
> 6. content applies to a PostgreSQL version. (varchar) (like "all pg
> versions", "8.x","7.x"
>
> 7. title (varchar)
>
> 8. A short description (varchar) (this would be the content introduction)
>
> 9. status (varchar) (E for editing for published, R for rejected)
>
> 10. the actual content or the story
>
> 11. date created
>
> 12. date updated
>
> 13. content type (like how-to, article, tutorial, etc ..)
>
>
>
> Do we need more information about a PGDN content? Please let me know what
> you think.
>
>
>
> Ps. the category and the keywords of the content are saved elsewhere.
>
>
>
> Regards,
>
> Gevik.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
> 3. major version (numeric like 3) > > 4. minor version (numeric like 2 > > 5. revision. (numeric like 5) > > This makes a document version of 3.2.5 Not sure we actually need three-step versioning - just x.y should be enough in most (all?) cases. Or? > 6. content applies to a PostgreSQL version. (varchar) (like > "all pg versions", "8.x","7.x" Wouldn't it be better to have a linked table for this, and just a checkbox list where you can check each major version that applies? That will make it a lot easier to do filtering on it in the view (so you can have an option on pgdn to say "i only want to look at stuff that applies to 8.1"). Keeping this kind of data in a varchar field leads to lots of different ways of writing (some write 8, some write 8.x some write 8.* etc etc), and it's harder to process in a reasonable way. > 9. status (varchar) (E for editing for published, R for rejected) Do we need to keep rejected ones at all? > Do we need more information about a PGDN content? Please let > me know what you think. How does this scheme deal with multiple versions? Say I (not trustworthy, remember!) cerate a document. Then Dave approves it for publishing. Then I edit it. At this ponit, the old version should be visible on the site. Then Dave approves the new version, at which point the old one should go away (or be kept in version history, probably) and the new one should be published. //Magnus
I agree, the pub_id is generated automatically like HT1234(.htm) meaning the public name would be HT (for a HowTo document and 1234 as internal id) Regards, Gevik. > -----Original Message----- > From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- > owner@postgresql.org] On Behalf Of Oleg Bartunov > Sent: Thursday, June 30, 2005 1:03 PM > To: Gevik Babakhani > Cc: pgsql-www@postgresql.org > Subject: Re: [pgsql-www] PGDN content information proposal > > On Thu, 30 Jun 2005, Gevik Babakhani wrote: > > > Dear All, > > > > > > > > I would like to start a discussion regarding the content information and > > structure we would like to have in PGDN. > > > > Here is the proposal: > > > > > > > > The content in PGDN has the following: > > > > 1. Content id (of course) (sequence generated number) > > we need two id's once we allow updating document. One is a pub_id - > publicly accessed persistent id and msg_id - internal id. > > > > > 2. Author (user or author id) > > > > > > > > 3. major version (numeric like 3) > > > > 4. minor version (numeric like 2 > > > > 5. revision. (numeric like 5) > > > > This makes a document version of 3.2.5 > > > > > > > > 6. content applies to a PostgreSQL version. (varchar) (like "all pg > > versions", "8.x","7.x" > > > > 7. title (varchar) > > > > 8. A short description (varchar) (this would be the content > introduction) > > > > 9. status (varchar) (E for editing for published, R for rejected) > > > > 10. the actual content or the story > > > > 11. date created > > > > 12. date updated > > > > 13. content type (like how-to, article, tutorial, etc ..) > > > > > > > > Do we need more information about a PGDN content? Please let me know > what > > you think. > > > > > > > > Ps. the category and the keywords of the content are saved elsewhere. > > > > > > > > Regards, > > > > Gevik. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq
On Thu, 30 Jun 2005, Magnus Hagander wrote:
> How does this scheme deal with multiple versions?
> Say I (not trustworthy, remember!) cerate a document. Then Dave approves
> it for publishing. Then I edit it. At this ponit, the old version should
> be visible on the site. Then Dave approves the new version, at which
> point the old one should go away (or be kept in version history,
> probably) and the new one should be published.
That's why I suggest external pub_id, which is persistent and publicly
available id, and msg_id - another one for versionning. Then we need
mapping between pub_id and msg_id. In our CMS we have versions and revisions,
but I don't think it's needed here.
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
On Thu, 30 Jun 2005, Gevik Babakhani wrote: > I agree, the pub_id is generated automatically like HT1234(.htm) meaning the > public name would be HT (for a HowTo document and 1234 as internal id) I don't like this artificial binding and name flooding. > > Regards, > Gevik. > > >> -----Original Message----- >> From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- >> owner@postgresql.org] On Behalf Of Oleg Bartunov >> Sent: Thursday, June 30, 2005 1:03 PM >> To: Gevik Babakhani >> Cc: pgsql-www@postgresql.org >> Subject: Re: [pgsql-www] PGDN content information proposal >> >> On Thu, 30 Jun 2005, Gevik Babakhani wrote: >> >>> Dear All, >>> >>> >>> >>> I would like to start a discussion regarding the content information and >>> structure we would like to have in PGDN. >>> >>> Here is the proposal: >>> >>> >>> >>> The content in PGDN has the following: >>> >>> 1. Content id (of course) (sequence generated number) >> >> we need two id's once we allow updating document. One is a pub_id - >> publicly accessed persistent id and msg_id - internal id. >> >>> >>> 2. Author (user or author id) >>> >>> >>> >>> 3. major version (numeric like 3) >>> >>> 4. minor version (numeric like 2 >>> >>> 5. revision. (numeric like 5) >>> >>> This makes a document version of 3.2.5 >>> >>> >>> >>> 6. content applies to a PostgreSQL version. (varchar) (like "all pg >>> versions", "8.x","7.x" >>> >>> 7. title (varchar) >>> >>> 8. A short description (varchar) (this would be the content >> introduction) >>> >>> 9. status (varchar) (E for editing for published, R for rejected) >>> >>> 10. the actual content or the story >>> >>> 11. date created >>> >>> 12. date updated >>> >>> 13. content type (like how-to, article, tutorial, etc ..) >>> >>> >>> >>> Do we need more information about a PGDN content? Please let me know >> what >>> you think. >>> >>> >>> >>> Ps. the category and the keywords of the content are saved elsewhere. >>> >>> >>> >>> Regards, >>> >>> Gevik. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> Regards, >> Oleg >> _____________________________________________________________ >> Oleg Bartunov, sci.researcher, hostmaster of AstroNet, >> Sternberg Astronomical Institute, Moscow University (Russia) >> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ >> phone: +007(095)939-16-83, +007(095)939-23-83 >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 5: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faq > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Please remember that the content is eventually being extracted to static files to be put into CVS. An extra naming would introduce administrative tasks which someone has to do. Also someone has to name the external names and keep track of them. > -----Original Message----- > From: Oleg Bartunov [mailto:oleg@sai.msu.su] > Sent: Thursday, June 30, 2005 1:33 PM > To: Gevik Babakhani > Cc: pgsql-www@postgresql.org > Subject: Re: [pgsql-www] PGDN content information proposal > > On Thu, 30 Jun 2005, Gevik Babakhani wrote: > > > I agree, the pub_id is generated automatically like HT1234(.htm) meaning > the > > public name would be HT (for a HowTo document and 1234 as internal id) > > I don't like this artificial binding and name flooding. > > > > > Regards, > > Gevik. > > > > > >> -----Original Message----- > >> From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- > >> owner@postgresql.org] On Behalf Of Oleg Bartunov > >> Sent: Thursday, June 30, 2005 1:03 PM > >> To: Gevik Babakhani > >> Cc: pgsql-www@postgresql.org > >> Subject: Re: [pgsql-www] PGDN content information proposal > >> > >> On Thu, 30 Jun 2005, Gevik Babakhani wrote: > >> > >>> Dear All, > >>> > >>> > >>> > >>> I would like to start a discussion regarding the content information > and > >>> structure we would like to have in PGDN. > >>> > >>> Here is the proposal: > >>> > >>> > >>> > >>> The content in PGDN has the following: > >>> > >>> 1. Content id (of course) (sequence generated number) > >> > >> we need two id's once we allow updating document. One is a pub_id - > >> publicly accessed persistent id and msg_id - internal id. > >> > >>> > >>> 2. Author (user or author id) > >>> > >>> > >>> > >>> 3. major version (numeric like 3) > >>> > >>> 4. minor version (numeric like 2 > >>> > >>> 5. revision. (numeric like 5) > >>> > >>> This makes a document version of 3.2.5 > >>> > >>> > >>> > >>> 6. content applies to a PostgreSQL version. (varchar) (like "all pg > >>> versions", "8.x","7.x" > >>> > >>> 7. title (varchar) > >>> > >>> 8. A short description (varchar) (this would be the content > >> introduction) > >>> > >>> 9. status (varchar) (E for editing for published, R for rejected) > >>> > >>> 10. the actual content or the story > >>> > >>> 11. date created > >>> > >>> 12. date updated > >>> > >>> 13. content type (like how-to, article, tutorial, etc ..) > >>> > >>> > >>> > >>> Do we need more information about a PGDN content? Please let me know > >> what > >>> you think. > >>> > >>> > >>> > >>> Ps. the category and the keywords of the content are saved elsewhere. > >>> > >>> > >>> > >>> Regards, > >>> > >>> Gevik. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> Regards, > >> Oleg > >> _____________________________________________________________ > >> Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > >> Sternberg Astronomical Institute, Moscow University (Russia) > >> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > >> phone: +007(095)939-16-83, +007(095)939-23-83 > >> > >> ---------------------------(end of broadcast)-------------------------- > - > >> TIP 5: Have you checked our extensive FAQ? > >> > >> http://www.postgresql.org/docs/faq > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/docs/faq > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83
Hi, Regarding to versioning: here is what I thought when creating a document and versioning. Step 1: You choose a documenttype like an Article or a HowTo. The document gets version 1.0 Step 2: You write your content and save it under a category. Document gets status 'E' for still Editing. Step 3: You request the document to be published. Document gets status 'T' for requesT to be published. At this point you cannot edit your document anymore! Because It is being review by a publisher Let's say the document is approved and published. Which make the document to be of status 'P' and for example version 1.0.0 If you decide to change the document after it is published you have to choose from: 1. make a large change, which makes your document version 2.0 2. make a minor change, which makes your document version 1.1 Regarding the 3 way versioning: this was just an idea. I agree that two way versioning is also good enough. Regards, Gevik. > -----Original Message----- > From: pgsql-www-owner@postgresql.org [mailto:pgsql-www- > owner@postgresql.org] On Behalf Of Magnus Hagander > Sent: Thursday, June 30, 2005 1:17 PM > To: Gevik Babakhani; pgsql-www@postgresql.org > Subject: Re: [pgsql-www] PGDN content information proposal > > > 3. major version (numeric like 3) > > > > 4. minor version (numeric like 2 > > > > 5. revision. (numeric like 5) > > > > This makes a document version of 3.2.5 > > Not sure we actually need three-step versioning - just x.y should be > enough in most (all?) cases. Or? > > > > 6. content applies to a PostgreSQL version. (varchar) (like > > "all pg versions", "8.x","7.x" > > Wouldn't it be better to have a linked table for this, and just a > checkbox list where you can check each major version that applies? That > will make it a lot easier to do filtering on it in the view (so you can > have an option on pgdn to say "i only want to look at stuff that applies > to 8.1"). > Keeping this kind of data in a varchar field leads to lots of different > ways of writing (some write 8, some write 8.x some write 8.* etc etc), > and it's harder to process in a reasonable way. > > > > 9. status (varchar) (E for editing for published, R for rejected) > > Do we need to keep rejected ones at all? > > > > Do we need more information about a PGDN content? Please let > > me know what you think. > > How does this scheme deal with multiple versions? > Say I (not trustworthy, remember!) cerate a document. Then Dave approves > it for publishing. Then I edit it. At this ponit, the old version should > be visible on the site. Then Dave approves the new version, at which > point the old one should go away (or be kept in version history, > probably) and the new one should be published. > > //Magnus > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend