[wp-trac] Re: [WordPress Trac] #9388: safety guard for
publish_future_post
WordPress Trac
wp-trac at lists.automattic.com
Sat Apr 4 21:26:36 GMT 2009
#9388: safety guard for publish_future_post
--------------------------+-------------------------------------------------
Reporter: hailin | Owner: anonymous
Type: defect (bug) | Status: new
Priority: normal | Milestone: 2.8
Component: General | Version: 2.7.1
Severity: normal | Keywords:
--------------------------+-------------------------------------------------
Comment(by hakre):
Replying to [comment:11 westi]:
> Replying to [comment:10 hakre]:
> > westi: what should a cron subcomponent do? should be no deal to code
one.
>
> What we need is a good generic design for storing the cron entries.
>
> Each one needs to be stored independently in the database so as to avoid
all the caching collision issues that we see on adding/removing of cron
entries which cause some to get lost on busy sites / multiserver
environments like wp.com
>
> We need to work out where the best place to store these is.
>
> Is it a new table or should we be storing things in an existing/new meta
place??
>
> A proposal for the storage of the cron entries would be a good place to
start. Migrating the code should be simple but we need to get the storage
design correct first.
ideally a new database table can do the job. re-using any of the existing
ones does not make so much sense to me, wp_options doesn't seem fitting as
well as it isn't wp_postmeta. mainly because of the index design, should
get fast access for inset, update and delete. if it should be used for
WP.com i think a blogid must be provided as well like in the options?
--
Ticket URL: <http://core.trac.wordpress.org/ticket/9388#comment:12>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list