[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