Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abstract storage backend so that custom tables aren't required #156

Closed
westonruter opened this issue Jan 15, 2014 · 9 comments
Closed

Abstract storage backend so that custom tables aren't required #156

westonruter opened this issue Jan 15, 2014 · 9 comments
Assignees
Milestone

Comments

@westonruter
Copy link
Contributor

In terms of where/how log entries are stored, there is a wp_stream_log_handler and there is also a wp_stream_no_tables filter (see #147). However, these filters don't touch on changing how log entries are read back out of the system.

In the case of sites running on WordPress VIP or for sites located on hosts which disallow custom tables, it would be great if the DB storage could be abstracted. Two storage backends could be included, one for using the existing custom tables, and then another (fallback) one which uses posts, postmeta, and other standard tables.

@frankiejarrett
Copy link
Contributor

This is an excellent idea, just need someone to champion it.

@shadyvb
Copy link
Contributor

shadyvb commented Feb 3, 2014

I think it should be delayed till #65 is cleared so table structure is more mature with the new fields added for site_id and blog_id. I'll probably take care of it then.

@powelski powelski self-assigned this Feb 4, 2014
@westonruter
Copy link
Contributor Author

We may want to abstract this to the point where the the data is interacted with via a REST interface. This would ensure that the API is suitable for remote data storage.

@westonruter
Copy link
Contributor Author

Of course, abstracting the storage backend also entails abstracting the querying interface. You gotta be able to get the data back out!

@shadyvb
Copy link
Contributor

shadyvb commented Apr 28, 2014

Lets just say that lots of stuff is gonna change 😆

@bordoni
Copy link
Contributor

bordoni commented May 1, 2014

Would be awesome to be able to send these logs to something like ElasticSearch to be used with something like Kibana

@shadyvb
Copy link
Contributor

shadyvb commented May 1, 2014

@bordoni That's the plan! 😄 /five!

@gedex
Copy link

gedex commented May 1, 2014

If logs are going to be sent to external service, it would be good to defer all logs into temporary stack and then submit all deferred logs in one request to that external service. During page load lifecycle there might be dozen of action-callbacks being logged, I think it's good for performance to avoid dozen of external requests too.

@shadyvb
Copy link
Contributor

shadyvb commented May 1, 2014

@gedex Sure, we'll need to tweak the logger to allow sending stuff in patches, via cron, or via async requests.

@shadyvb shadyvb mentioned this issue May 16, 2014
11 tasks
@frankiejarrett frankiejarrett added this to the 2.0.0 milestone Jun 5, 2014
frankiejarrett added a commit that referenced this issue Aug 22, 2014
Issue 152: Multisite support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants