More Categories please!

ruud · 2012-08-28 19:04:49

Heheh… It doesn’t hurt to compare what TXP 4.5 does to what various unlimited categories plugins do. I have no doubt unlimited categories are slower. The question is: how much slower? Makks claims there is a difference large enough to keep the 2-category setup alongside unlimited categories for performance reasons, so I’m curious how big the difference actually is.

I would love to see unlimited categories in core, so I can drop the privately maintained plugin I’m currently using for that purpose, even if that means I have to find a way to migrate the current setup to whatever you have planned for TXP 4.6. No, I never bothered to measure the performance impact. I needed the feature, so I just implemented it as efficiently as I could (read: could be worse, could be better).

wet · 2012-08-28 19:10:49

I assume that we will have to use a bit of de-normalization of our still hypothetical article_categories (or article_meta, or maybe even entity_meta) table, both due to speed considerations and also to mimick the two “legacy” categories. This is just a working theory at the current time of course.

makss · 2012-08-28 19:26:04

ruud wrote:

Do you have some numbers (benchmarks) that show how much difference there is between the current limited (2) categories and unlimited categories?

I did not make performance measurements. :(
1. limited category – make select from one table, it’s very fast. (used index on sql table)
2. Normalized unlimited category (rss_unlimited_categories) – used select from 3 linked tables. (used indexes)
3. De-normalization unlimited category solution will use select from 2 linked tables, it will be faster than the 2 point, but slower than the first. In implementing this option will need to accurately track data integrity. (used indexes)
4. Extra De-normalization unlimited category (bad idea) select from one table with like '%bla-bla%' (not used sql index) The more articles, the more slowly will work. It is very difficult to maintain the integrity of the data, but if their name tags, then the integrity of not much you can think about.

wet wrote:

It is not reasonable to assume that core will adopt anything from existing plugins.

I really like the current implementation limited category (category1, category2) and my post calls to leave it without changes. If the plans include adding unlimited category, this must be done in addition to a limited category and not in place of them.

Enough for me implementation unlimited category in the form of plugin, but need rewrite a lot of code. (old code for Textpattern 4.0 and many patches that it is still working now)

Last edited by makss (2012-08-28 19:48:34)

ruud · 2012-08-28 21:46:19

I wonder how you can keep offering cat1/2 functionality when switching to unlimited categories.

Might be easier to keep cat1/2, add unlimited categories (normalized), and force the user to choose which one is used on a specific site (not both) and perhaps only offer the choice for those that upgrade, not for those that do a fresh install (deprecating cat1/2). Moving from cat1/2 to unlimited cats automatically during a TXP upgrade, seems tricky. Imagine doing that on a website with thousands of articles.

@makks, how would option #3 and #4 work? #4 sounds like how keywords are done now, but how would you do #3?

Gocom · 2012-08-28 23:05:53

Only thing I’m worried about overheat and how complex or generic (one tool fits for all) the whole meta/custom/relation thing is going to be, or whether the tables are organized, let’s say, by type.

One thing I’ve newer understood why the Textpattern table doesn’t store sections and categories using the ID, opposed to the name. Is that planned too?

makss · 2012-08-29 05:31:16

Functionality cat1/2 and unlimited category not intersect, so you can not restrict the user to choose.
In rss_unlimited_categories I just added the option to “hide cat1/2 in admin interface” to have fewer questions.

ruud wrote:

how would you do #3?

Create addition table, some like this:

CREATE TABLE IF NOT EXISTS `txp_article_category` (
  `article_id` int(11) NOT NULL default '0',
  `category` varchar(64) NOT NULL default '0',
  UNIQUE KEY `article_category` (`article_id`,`category`),     -- used UNIQUE KEY, not PRIMARY !
  KEY `article_id` (`article_id`),
  KEY `category` (`category`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Table textpattern unchanged.

Last edited by makss (2012-08-29 05:41:50)

ruud · 2012-08-29 10:10:33

makss wrote:

Functionality cat1/2 and unlimited category not intersect, so you can not restrict the user to choose.
In rss_unlimited_categories I just added the option to “hide cat1/2 in admin interface” to have fewer questions.

Technically, you can make cat1/2 and unlimited cats work completely separate, but as you point out, offering both options results in questions from users, so for that reason, I think it’s better if users choose between the one or the other. Preferably with a migration option, for those that use cat1/2 without a category being specifically cat1 or cat2 and just want more than 2 categories per article. If both were offered, I’d probably write a plugin to hide one of them.

 `category` varchar(64) NOT NULL default '0',

And #2 (normalized) would have int instead of varchar, right?

makss · 2012-08-29 14:33:42

ruud wrote:

 `category` varchar(64) NOT NULL default '0',

And #2 (normalized) would have int instead of varchar, right?

Yes, that’s right.

Textpattern CMS

Textpattern CMS support forum

#13 2012-08-28 19:04:49

Re: More Categories please!

#14 2012-08-28 19:10:49

Re: More Categories please!

#15 2012-08-28 19:26:04

Re: More Categories please!

#16 2012-08-28 21:46:19

Re: More Categories please!

#17 2012-08-28 23:05:53

Re: More Categories please!

#18 2012-08-29 05:31:16

Re: More Categories please!

#19 2012-08-29 10:10:33

Re: More Categories please!

#20 2012-08-29 14:33:42

Re: More Categories please!

Board footer