Grab a seat. On Delaying 2.2, separating tables

[Boris Anthony]

On 15-Apr-07, at 7:51 PM, Matt Mullenweg wrote:

> Robin Adrianse wrote:
>> I don't agree. One of my big, BIG pet peeves of the 2.1 release  
>> was that
>> link and post categories were, so to speak, "unified." If we're  
>> going to
>> separate them in the UI, then we should really put them in  
>> separate tables.
>
> By that argument we should have separate tables for posts, pages,  
> uploads, rss feeds, rewrite rules...

just a question of where you draw the lines and why. I think most  
people here agree some lines were poorly drawn. We all make mistakes. :)

--

+1 for the ongoing vote.


insofar as tagging is concerned, please don't try to reinvent the  
wheel. Please check out how other systems do it. Please check out  
other codes bases. Please talk to people who have done this on  
monumental scales. Tags are seriously non-trivial thing to do,  
especially in a scaleable way. Consider your DB schemas deeply. Plan  
out what functionalities you will need and want. Please please do not  
do this half-assedly. :)

The world is watching. ;)

B.

-------------------------
Boris Anthony
Designer and Web Architect
http://globalvoicesonline.org/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Doug Stewart]

On 4/15/07, Matt Mullenweg <m@...> wrote:
> Robin Adrianse wrote:
> > I don't agree. One of my big, BIG pet peeves of the 2.1 release was that
> > link and post categories were, so to speak, "unified." If we're going to
> > separate them in the UI, then we should really put them in separate tables.
>
> By that argument we should have separate tables for posts, pages,
> uploads,

Yes, yes, yes.  Content.  I cannot count the number of times that
people have wanted to "categorize" pages.  They're fundamentally
different than each other and to cram them into the same table is a
bad notion, DB design-wise.

> rss feeds, rewrite rules...

No, no. Options

--
-Doug

http://literalbarrage.org/blog/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

On 4/15/2007 Doug Stewart wrote:
> They're fundamentally
> different than each other and to cram them into the same table is a
> bad notion, DB design-wise.

Would you mind explaining why? It has worked quite well for us thus far.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Doug Stewart]

On 4/15/07, Matt Mullenweg <m@...> wrote:
> On 4/15/2007 Doug Stewart wrote:
> > They're fundamentally
> > different than each other and to cram them into the same table is a
> > bad notion, DB design-wise.
>
> Would you mind explaining why? It has worked quite well for us thus far.
>

Let's take a look at the posts table for a second.

What use is "post_parent" to a post, exactly?  I can plainly see the
value for hierarchical pages and even uploads, but not posts.  What
about post_mimetype?  No value there, either.

How about "pinged" for uploads?  What sort of sense does that make?
And "post_content" is synonymous with "upload description"?  You're
getting peanut butter in the floor cleaner, to mix two slightly
disparate cultural references...

You're carrying unnecessary (and confusing) information with each
object type you cram into the posts table.  The only reason that it
has worked quite well thus far is that people are confident enough in
the overall quality and direction of WordPress to commit vast amounts
of their own time, blood, sweat and tears to the proposition that
WordPress is worth developing.  It has resulted in some gnarly hacks
in the past and I'm sure there will be some in the future

Which is easier, "SELECT * FORM wp_posts WHERE post_type='post'" or
"SELECT * FROM wp_posts" (in a DB purist's dream)?  In the second
example, the table name is actually descriptive of what it contains
(or we could just rename it to wp_content or somesuch and be done with
it, I suppose).  The current WP example is _not_ descriptive and it
carries a ton of informational baggage with each additional post,
upload and page that authors create.

Posts and pages are intended for different ends, yes?  The Codex says
so.  They are _similar_ but they are not the same, nor should they be,
IMNSHO.  "Alikeness" is not a factor for inclusion in a DB schema -
"synonymous" errrm, -ness _is_.

For example:

Let's say I was happily categorizing "Cars I've Seen" in a database.
I create a table called "cars" and begin storing "Lambroghini",
"Bentley", "Ford", "AMC" and the date and location on which I've seen
each.  Sometime down the road, I decide I really want to track "Planes
I've Seen" as well, so I simply begin to add "Learjet", "Super 80",
"747", etc. into the "cars" table.  They're vehicles, sure, and I've
seen 'em just like I've seen the cars, but they're fundamentally
different from what I initially intended the "cars" table to house.
Anyone coming along after me is going to be in for some serious
headscratching before they can suss out just what the devil I was
doing.

I do not understand the resistance to good DB design.  Lumping pages
in with posts was a kludge and is one that could use righting should
we ever care to scrub the entire schema.

--
-Doug

http://literalbarrage.org/blog/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Boris Anthony]

On 15-Apr-07, at 10:57 PM, Matt Mullenweg wrote:

> On 4/15/2007 Doug Stewart wrote:
>> They're fundamentally
>> different than each other and to cram them into the same table is a
>> bad notion, DB design-wise.
>
> Would you mind explaining why? It has worked quite well for us thus  
> far.

they are different content types, with different metadata, different  
uses and different interactions. Different needs etc.

counter argument to above: filesystem. handles many differnt content  
types in the same "database" (the filesystem).

argue amongst yourselves. ;p

but two last words: drupal + nodes.

*cough*

/me runs away

=D

B.

-------------------------
Boris Anthony
Designer and Web Architect
http://globalvoicesonline.org/

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Andy Skelton]

Matt, I have not seen your statements on this matter sway a single
person. The other committing devs have come out against releasing with
tags on the 2.2 milestone date.

The correctness of any one implementation of tags is not the subject
here. It's the development process.

To include a premature feature in an on-time release degrades the
quality of the product. I refer to not only the code but the state of
the community. Increments are supposed to be in the direction of
better, not merely more. Better would be to release on-time with a
modest set of stable upgrades.

To block release while the one new feature gets sorted out would be a
maladjustment of priorities. If 2.2 seems light on sex appeal, so be
it. Better to keep the release date as promised.

Proposed plan of action:

Don't touch trunk. Leave trunk out of this.
Create a 2.2 branch, remove tags from it, ship 2.2-alpha.

Andy
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Computer Guru]

That sounds awesome to me :)

I've been worrying about my site, I run it from the trunk at all times
(scary, I know) - and just yesterday I deleted UTW from it and switched to
WP22's tags instead. This method would minimize risk and be good all around.

*phew*

Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/

> -----Original Message-----
> From: wp-hackers-bounces@... [mailto:wp-hackers-
> bounces@...] On Behalf Of Andy Skelton
> Sent: Monday, April 16, 2007 8:29 AM
> To: wp-hackers@...
> Subject: Re: [wp-hackers] Grab a seat. On Delaying 2.2, separating
> tables
>
> Matt, I have not seen your statements on this matter sway a single
> person. The other committing devs have come out against releasing with
> tags on the 2.2 milestone date.
>
> The correctness of any one implementation of tags is not the subject
> here. It's the development process.
>
> To include a premature feature in an on-time release degrades the
> quality of the product. I refer to not only the code but the state of
> the community. Increments are supposed to be in the direction of
> better, not merely more. Better would be to release on-time with a
> modest set of stable upgrades.
>
> To block release while the one new feature gets sorted out would be a
> maladjustment of priorities. If 2.2 seems light on sex appeal, so be
> it. Better to keep the release date as promised.
>
> Proposed plan of action:
>
> Don't touch trunk. Leave trunk out of this.
> Create a 2.2 branch, remove tags from it, ship 2.2-alpha.
>
> Andy
> _______________________________________________
> wp-hackers mailing list
> wp-hackers@...
> http://lists.automattic.com/mailman/listinfo/wp-hackers

_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Andy Skelton wrote:
> Matt, I have not seen your statements on this matter sway a single
> person. The other committing devs have come out against releasing with
> tags on the 2.2 milestone date.

That's disappointing, I thought the discussion on the terms thread was
generating some ideas better than the existing implementation or the
"separate tags table." Also read through #3723.

Most importantly, there's movement around an issue that sat around forever.

The comments from people using the current implementation have been
good, so I think we have the user side of things down and I'm
comfortable shipping with that. I think if we get the backend down in a
way that doesn't compromise terms or performance we have a neat little
feature done.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Peter Westwood]

On Mon, April 16, 2007 9:07 am, Matt Mullenweg wrote:
> Andy Skelton wrote:
>> Matt, I have not seen your statements on this matter sway a single
>> person. The other committing devs have come out against releasing with
>> tags on the 2.2 milestone date.
>
> That's disappointing, I thought the discussion on the terms thread was
> generating some ideas better than the existing implementation or the
> "separate tags table." Also read through #3723.
>

There are a lot of non tag releated changes that have gone in to 2.2
already.  There must be other things that we can pull out for the release
announcement that make it worth people upgrading:

# Updated Blogger importer
# APP
# WordPress xmlrpc api
# Mail sending improvements using phpmailer
# class-pop3 update
# Performance Improvements.
# Bug fixes, lots of.

http://trac.wordpress.org/query?status=closed&milestone=2.2

> Most importantly, there's movement around an issue that sat around
> forever.
>
> The comments from people using the current implementation have been
> good, so I think we have the user side of things down and I'm
> comfortable shipping with that. I think if we get the backend down in a
> way that doesn't compromise terms or performance we have a neat little
> feature done.
>

Just because we have an acceptable user interface for interacting with
tags does not mean they are ready for release.

The level of discussion around the schema used for storing these
relationships shows how unhappy people are with the current
implementation.

As stated elsewhere, in this thread, we can never provide a complete API
for plugin authors and as such they will end up interacting with the db.
Therefore we need to be happy with the db schema before we release -
otherwise we have the potential to annoy a lot of people - and break any
number of plugins in the future when we rework the schema.

We need to get the groundwork done for the schema that everyone is happy
with before tags are released.

Tweaking it later is fine.

westi
--
Peter Westwood <peter.westwood@...>
http://blog.ftwr.co.uk
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Peter Westwood wrote:
> There are a lot of non tag releated changes that have gone in to 2.2
> already.  There must be other things that we can pull out for the release
> announcement that make it worth people upgrading:

I agree there's lots of good stuff under the hood in 2.2, but nothing
that would really compel someone to upgrade, unless perhaps they were
using a desktop client that uses the new APIs.

> Just because we have an acceptable user interface for interacting with
> tags does not mean they are ready for release.

To clarify I meant the interface is fine for a first version to ship.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Peter Westwood]

On Mon, April 16, 2007 9:39 am, Matt Mullenweg wrote:

> Peter Westwood wrote:
>> There are a lot of non tag releated changes that have gone in to 2.2
>> already.  There must be other things that we can pull out for the
>> release
>> announcement that make it worth people upgrading:
>
> I agree there's lots of good stuff under the hood in 2.2, but nothing
> that would really compel someone to upgrade, unless perhaps they were
> using a desktop client that uses the new APIs.
>

We shouldn't need lots of snazy features to compel people to upgrade.

WordPress has a bit of a reputation for new releases being centred around
adding features ( and be way of a side effect new bugs) with a little bit
of bug fixing on the side.

We have too many bugs that languish around and don't get fixed while we
concentrate on adding new features.

We need to understand that reliability is a selling point and that just
fixing a large number of those long standing bugs is good enough for a non
major version release.

Yes a release needs some new features.  But it doesn't need to be
overflowing with new features - the fact that a lot of long-standing bugs
have been fixed does give people a reason to upgrade.

westi
--
Peter Westwood <peter.westwood@...>
http://blog.ftwr.co.uk
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Matt Mullenweg]

Peter Westwood wrote:
> We shouldn't need lots of snazy features to compel people to upgrade.

Well, at least amoung the folks I've talked to new features seem to be
the primary motivator for upgrades, even over security fixes. I'm not
saying that's right, but just reality. At least one "hook" is needed, a
release should appeal to people's emotional side as well.

> We have too many bugs that languish around and don't get fixed while we
> concentrate on adding new features.

Given the feature vs bugfix ratio in 2.2, I think we're safely over that
bump. :)

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org
http://automattic.com | http://akismet.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Robert Deaton]

On 4/16/07, Matt Mullenweg <m@...> wrote:
> > Just because we have an acceptable user interface for interacting with
> > tags does not mean they are ready for release.
>
> To clarify I meant the interface is fine for a first version to ship.

Then you have clearly missed the point of this entire thread. This
isn't about an interface for users. This is about the backend, the
schema, everything but the UI.

--
--Robert Deaton
http://lushlab.com
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Elliotte Harold]

Peter Westwood wrote:

> There are a lot of non tag releated changes that have gone in to 2.2
> already.  There must be other things that we can pull out for the release
> announcement that make it worth people upgrading:
>
> # Updated Blogger importer
> # APP
> # WordPress xmlrpc api
> # Mail sending improvements using phpmailer
> # class-pop3 update
> # Performance Improvements.
> # Bug fixes, lots of.
>

Don't forget Atom 1.0 support. Long overdue and enough for me to
recommend everyone upgrade for that alone.

--
Elliotte Rusty Harold  elharo@...
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers

[Chris Meller]

On 4/15/07, Computer Guru <computerguru@...> wrote:
>
> +1
>
> The UTW import script is BROKEN and imports "Multiple Word Tags" as
> "Multiple-Word-Tags" - but that's not the point.


That's because that's what UTW stores them as in its "<prefix>_tags" table.
I thought it better to go with exactly what they had, rather than trying to
guess and potentially removing a legit "-". Who designs a system that stores
"-" and " " the same? Ugh...

I fully agree that we should split tags out into their own tables. It was a
pain in the ass trying to keep up with the increasingly-complex table design
when I was writing the UTW importer. Granted I've spent a limited amount of
time with the new features, but I'm also not confident enough in a stable
2.2 release yet. I say delay it (maybe even skip to 2.3?) and get out a
truly quality release.

--
Chris Meller
chris@...
_______________________________________________
wp-hackers mailing list
wp-hackers@...
http://lists.automattic.com/mailman/listinfo/wp-hackers