Schema updates
Owen Winkler
branch is to make the required schema changes to:
* Enable timezone support
* Add the required third datetime field so that feeds don't necessarily
republish old posts when they're edited
* Add a parameters field to the rewriterules table so that rules can be
matched without having all of the parameters specified (see below)
* Make any changes as might be required for ACL
* Add taxonomy tables for conversion from tags
I'm using the code from Andrew da Silva's timezone branch to do the date
updates. The new system uses the PHP DateTime object, which has much
improved timezone support.
A result is that all dates are stored in the database as unsigned
integers, and are converted to the HabariDateTime class when loaded.
This actually gives a lot of flexibility with how dates can be handled,
and I think serves as a good example for a future String class (for
replacing the Format class altogether - more on this in a separate,
future email).
The rewrite rule table change would add a single field that would
contain a serialized array of default parameters. As an example of how
this would be used, consider a rule that would use the URL
"/amazing_stories" to show the posts tagged "amazing".
The regex would be:
%^/amazing_stories$%
The rule can be set to dispatch to
UserThemeHandler::display_posts_by_tag(), but it won't supply any data
about which tag to display, since the regex doesn't match the tag data.
If we added an array to the new parameters field that looked like this:
array('tag'=>'amazing')
Then the rule would be able to properly dispatch.
This would create incredible flexibility in the rewrite system, allowing
you to rewrite any arbitrary URL to any data-centric URL that the system
can answer for.
Anyway. I'd like to get a review on the code so far, and some opinions
on how to proceed. As I said, the code is mostly Andrew's but with some
tweaks of my own to get things working, specifically some enhancements
in the Locale class for sprintf()-like parameter support. I'd
especially like to know how people think we should stage the schema changes.
I was thinking originally we could do them all at once, but it looks
like features might not be complete to wait for all of them before we
start making changes. What do you think?
Owen
Randy Walker
Seems beneficial. I don't understand taxonomy/tags.
Keep scheming.
+1
~Randy
Michael C. Harris
>
> I've started a massive update in the schema06 branch. The goal of this
> branch is to make the required schema changes to:
>
> * Enable timezone support
> * Add the required third datetime field so that feeds don't necessarily
> republish old posts when they're edited
> * Add a parameters field to the rewriterules table so that rules can be
> matched without having all of the parameters specified (see below)
> * Make any changes as might be required for ACL
> * Add taxonomy tables for conversion from tags
I support all of these changes (though the rewrite stuff is more than
my brain can bear at this stage).
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari
Arthus Erea
These changes will definitely enable some exciting functionality.
I think the best course of action is to get the basic schema/database
interaction nailed down in a branch so Habari is still usable.
Once the new functionality is at a base level of usability, I say we
merge it to trunk to finish the rest up–seemed to work well for
Monolith.
Sean T Evans
Hash: SHA1
Owen Winkler wrote:
> I've started a massive update in the schema06 branch. The goal of this
> branch is to make the required schema changes to:
>
> * Enable timezone support
Huzzah!
> * Add the required third datetime field so that feeds don't necessarily
> republish old posts when they're edited
Again, Huzzah!
> * Add a parameters field to the rewriterules table so that rules can be
> matched without having all of the parameters specified (see below)
I'm not familiar enough with how this works to provide meaningful
feedback, but it sounds like a very useful function.
> * Make any changes as might be required for ACL
Sounds reasonable once we know what's required.
> * Add taxonomy tables for conversion from tags
>
You've gone into some detail about this on IRC, and it sounds like
(assuming it's implemented properly) it'll basically be a transparent
change for users, but will add a lot of flexibility for other sorts of
functions (my Magic Tags concept comes to mind). However, I think for
the community as a whole a more detailed description of what you're
trying to accomplish with this change, and some of the ideas for how it
can be used would be useful sent to the list.
>
> I was thinking originally we could do them all at once, but it looks
> like features might not be complete to wait for all of them before we
> start making changes. What do you think?
What are the benefits of making the change in one fell swoop? It seems
like the potential for breakage on some of these is high enough that a
more measured approach to implementing the schema changes may be in order.
- --
Sean T. Evans
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIkSeZmQpMBUWJpdsRAmfNAKCD3tQRSUehvMEZ5jfBcWdXq0z9zwCdEcIC
0a764RQzU6Mp/ad8UDYwFCc=
=3vmv
-----END PGP SIGNATURE-----
Andrew da Silva
explanations.
rick c
On Jul 30, 10:25 pm, Owen Winkler <epit...@gmail.com> wrote:
> I've started a massive update in the schema06 branch. The goal of this
> branch is to make the required schema changes to:
>
> * Enable timezone support
> * Add the required third datetime field so that feeds don't necessarily
> republish old posts when they're edited
> * Add a parameters field to the rewriterules table so that rules can be
> matched without having all of the parameters specified (see below)
an easily used way to manipulate the rewriterules.
> * Make any changes as might be required for ACL
> * Add taxonomy tables for conversion from tags
>
needed for multi-user sites and tagging flexibility.
I can understand that making these schema changes all at once will
save pain in the future if it saves having to make major database
changes over the next several releases, and so support them. If we
implement them all before 0.6, it will be probably be more than a
couple of months before the next release, though, especially if we
don't forget about podcasting.
Rick Cockrum
Chris J. Davis
(since one of them makes my auto major revision plugin actually
doable). I think that taking a more cautious approach and updating
the schema over time, so that we can adequately test each change,
without having to worry about which change is breaking habari.
Just some thoughts.
Chris
Chris Meller
Thanks for working on this, Owen.
These changes will definitely enable some exciting functionality.
I think the best course of action is to get the basic schema/database
interaction nailed down in a branch so Habari is still usable.
Once the new functionality is at a base level of usability, I say we
merge it to trunk to finish the rest up–seemed to work well for
Monolith.
I agree. Get it nailed down in a branch and then give everyone a day or two warning just to make sure too many things don't break unexpectedly.
Rich Bowen
* Enable timezone support
Rich Bowen
* Add the required third datetime field so that feeds don't necessarily
republish old posts when they're edited
Michael C. Harris
> On Jul 30, 2008, at 22:25, Owen Winkler wrote:
> >
> > * Add the required third datetime field so that feeds don't
> > necessarily republish old posts when they're edited
>
> This, too, is fabulous. I've come to avoid editing posts, or even
> marking posts as a "no comments allowed" when they're getting
> spam-flooded, because of this ... ahem ... feature. Thanks so much.
Yes, obviously this needs to change*. Do we want to offer the option
of bumping things in the feed ? Should we provide a UI element when
updating a post to do so ? Rich, I noted your update to your exploding
glass post, which I think was interesting to have updated in the feed.
Were you unhappy with that ?
* it's only this way because the AtomPub spec says we SHOULD order by
edited, and the Atom Syndication Format spec doesn't specify ordering.
Though I wasn't a committer when I supplied the patch, I take
responsibility for the change. I had hoped the other half of the
change wouldn't take so long.