@Euan T
one question...
In SimpleLike the ENGINE type is InnoDB. But in Myalerts the ENGINE type is MyISAM when table is inserted in DB.
Not better change to InnoDB here too?
(2015-07-29, 06:31 AM)Euan T Wrote: [ -> ]Yes, this is a known issue and something that will be fixed in 2.1.0. It was planned for 2.0.0, but I was way behind schedule already.
Thanks Euan.
If I may offer a suggestion: you don't need a whole extra table to record alerts. All the information is there in the MyBB DB already; you just need somewhat complex SQL statements to get it.
For instance: to get unread posts, use the
threadsread table and get posts where
posts.dateline > threadsread.dateline. Combine this with
threads.lastpost > users.lastvisit to get new threads since a user's last visit. A similar statement can be used to get unread PMs.
If you do it this way, you don't have to worry about deleting old alerts.
This is what I do with my
GCM Push Notifications plugin to get new threads and PMs. If needed, I can help you with the statements or you can check out my plugins repo.
You can just combine queries for for unread posts and unread PMs, and allow external plugins to add their own queries so they can tie in with MyAlerts.
(2015-07-29, 08:38 AM)martec Wrote: [ -> ]@Euan T
one question...
In SimpleLike the ENGINE type is InnoDB. But in Myalerts the ENGINE type is MyISAM when table is inserted in DB.
Not better change to InnoDB here too?
It might be, yes. Not everybody uses InnoDB though, and it's used here so that I can add foreign keys for users and posts.
(2015-07-29, 10:14 AM)Marc A Wrote: [ -> ] (2015-07-29, 06:31 AM)Euan T Wrote: [ -> ]Yes, this is a known issue and something that will be fixed in 2.1.0. It was planned for 2.0.0, but I was way behind schedule already.
Thanks Euan.
If I may offer a suggestion: you don't need a whole extra table to record alerts. All the information is there in the MyBB DB already; you just need somewhat complex SQL statements to get it.
For instance: to get unread posts, use the threadsread table and get posts where posts.dateline > threadsread.dateline. Combine this with threads.lastpost > users.lastvisit to get new threads since a user's last visit. A similar statement can be used to get unread PMs.
If you do it this way, you don't have to worry about deleting old alerts.
This is what I do with my GCM Push Notifications plugin to get new threads and PMs. If needed, I can help you with the statements or you can check out my plugins repo.
You can just combine queries for for unread posts and unread PMs, and allow external plugins to add their own queries so they can tie in with MyAlerts.
Hi,
Using an extra table makes things much easier for querying and inserting. It also provides much more power for third party integration (and adds the possibility of accessing alerts from other software such as a mobile app via an API). During the development I did consider other approaches such as reading the data out of existing tables every page load, but having it all indexed in a single table decreases load and speeds up the whole process for the majority of page loads, with the only major overhead being when a new post is posted or a PM sent (and even then, it's only 2 queries or so). I wanted to keep the system light so that it can be ran on any board including big boards without any issues.
(2015-07-29, 10:27 AM)Euan T Wrote: [ -> ] (2015-07-29, 08:38 AM)martec Wrote: [ -> ]@Euan T
one question...
In SimpleLike the ENGINE type is InnoDB. But in Myalerts the ENGINE type is MyISAM when table is inserted in DB.
Not better change to InnoDB here too?
It might be, yes. Not everybody uses InnoDB though, and it's used here so that I can add foreign keys for users and posts.
(2015-07-29, 10:14 AM)Marc A Wrote: [ -> ] (2015-07-29, 06:31 AM)Euan T Wrote: [ -> ]Yes, this is a known issue and something that will be fixed in 2.1.0. It was planned for 2.0.0, but I was way behind schedule already.
Thanks Euan.
If I may offer a suggestion: you don't need a whole extra table to record alerts. All the information is there in the MyBB DB already; you just need somewhat complex SQL statements to get it.
For instance: to get unread posts, use the threadsread table and get posts where posts.dateline > threadsread.dateline. Combine this with threads.lastpost > users.lastvisit to get new threads since a user's last visit. A similar statement can be used to get unread PMs.
If you do it this way, you don't have to worry about deleting old alerts.
This is what I do with my GCM Push Notifications plugin to get new threads and PMs. If needed, I can help you with the statements or you can check out my plugins repo.
You can just combine queries for for unread posts and unread PMs, and allow external plugins to add their own queries so they can tie in with MyAlerts.
Hi,
Using an extra table makes things much easier for querying and inserting. It also provides much more power for third party integration (and adds the possibility of accessing alerts from other software such as a mobile app via an API). During the development I did consider other approaches such as reading the data out of existing tables every page load, but having it all indexed in a single table decreases load and speeds up the whole process for the majority of page loads, with the only major overhead being when a new post is posted or a PM sent (and even then, it's only 2 queries or so). I wanted to keep the system light so that it can be ran on any board including big boards without any issues.
anything that will add that use more resource plz on/off in ACP.
ajax, mark read when clicked in link etc...
(2015-07-29, 10:45 AM)martec Wrote: [ -> ] (2015-07-29, 10:27 AM)Euan T Wrote: [ -> ] (2015-07-29, 08:38 AM)martec Wrote: [ -> ]@Euan T
one question...
In SimpleLike the ENGINE type is InnoDB. But in Myalerts the ENGINE type is MyISAM when table is inserted in DB.
Not better change to InnoDB here too?
It might be, yes. Not everybody uses InnoDB though, and it's used here so that I can add foreign keys for users and posts.
(2015-07-29, 10:14 AM)Marc A Wrote: [ -> ] (2015-07-29, 06:31 AM)Euan T Wrote: [ -> ]Yes, this is a known issue and something that will be fixed in 2.1.0. It was planned for 2.0.0, but I was way behind schedule already.
Thanks Euan.
If I may offer a suggestion: you don't need a whole extra table to record alerts. All the information is there in the MyBB DB already; you just need somewhat complex SQL statements to get it.
For instance: to get unread posts, use the threadsread table and get posts where posts.dateline > threadsread.dateline. Combine this with threads.lastpost > users.lastvisit to get new threads since a user's last visit. A similar statement can be used to get unread PMs.
If you do it this way, you don't have to worry about deleting old alerts.
This is what I do with my GCM Push Notifications plugin to get new threads and PMs. If needed, I can help you with the statements or you can check out my plugins repo.
You can just combine queries for for unread posts and unread PMs, and allow external plugins to add their own queries so they can tie in with MyAlerts.
Hi,
Using an extra table makes things much easier for querying and inserting. It also provides much more power for third party integration (and adds the possibility of accessing alerts from other software such as a mobile app via an API). During the development I did consider other approaches such as reading the data out of existing tables every page load, but having it all indexed in a single table decreases load and speeds up the whole process for the majority of page loads, with the only major overhead being when a new post is posted or a PM sent (and even then, it's only 2 queries or so). I wanted to keep the system light so that it can be ran on any board including big boards without any issues.
anything that will add that use more resource plz on/off in ACP.
ajax, mark read when clicked in link etc...
As always. As I said above, performance always has been and still is a major concern with this plugin, which is why it is built the way it is...
(2015-07-29, 10:49 AM)Euan T Wrote: [ -> ]As always. As I said above, performance always has been and still is a major concern with this plugin, which is why it is built the way it is...
great hear this...
As i use auto mark read i not need mark read when link is clicked etc... too i not need ajax refresh etc ... so on/off is good.
(2015-07-29, 10:27 AM)Euan T Wrote: [ -> ]Hi,
Using an extra table makes things much easier for querying and inserting. It also provides much more power for third party integration (and adds the possibility of accessing alerts from other software such as a mobile app via an API). During the development I did consider other approaches such as reading the data out of existing tables every page load, but having it all indexed in a single table decreases load and speeds up the whole process for the majority of page loads, with the only major overhead being when a new post is posted or a PM sent (and even then, it's only 2 queries or so). I wanted to keep the system light so that it can be ran on any board including big boards without any issues.
Yes, I agree having an extra table makes third party integration much easier. However, accessing alerts via an API would still be possible by simply exposing the results of your queries using MyBB's built-in xmlhttp.php and JSON. Any external access that's done properly should also update
threadsread.dateline and
users.lastvisit, so you don't have to worry about deleting alerts.
As for additional queries, you can combine SELECT statements into one giant query. For example:
SELECT
( SELECT 1 as alert_type, tid, dateline ... FROM ... WHERE ... ) -- for new threads
( SELECT 2 as alert_type, pmid, dateline ... FROM ... WHERE ... ) -- for new PMs
( SELECT x as alert_type, ... ) -- for third-party integration
ORDER BY dateline DESC
If combined like this, you technically only have one additional query for each page load and it shouldn't be significantly slower. Your current implementation would also require an additional query to delete old alerts. In the above example, the alert_type column determines what template is used to output the alert, or you can actually include the HTML right in the SELECT statement for even faster results.
Anyway, these changes are probably too large to implement ... but it's just a thought.
Does this plugin need PHP 5.4?
Okay I just took a deep breath...everythings fine. It's just a mod, and this is just myBB.
Now then. Have you tried having your mod enabled with guests posts?
I just got a fatal error that needs some looking at.
" Call to a member function getByCode() on a non-object in.... " in myAlerts.php
I'm somewhat shocked this was left unaddressed, myAlerts should not even be involved in guest posting,
Uninstalled until next release, please fix
(2015-07-30, 03:06 AM)whyy Wrote: [ -> ]Okay I just took a deep breath...everythings fine. It's just a mod, and this is just myBB.
Now then. Have you tried having your mod enabled with guests posts?
I just got a fatal error that needs some looking at.
" Call to a member function getByCode() on a non-object in.... " in myAlerts.php
I'm somewhat shocked this was left unaddressed, myAlerts should not even be involved in guest posting,
Uninstalled until next release, please fix
Fluoride sheeple rejoice!
Open up myalerts.php, and above line 891 AND 952 ADD
if ( !is_object( MybbStuff_MyAlerts_AlertTypeManager ) ) { return false; }
How long until the next error? Who knows. Author can i just add the above line right above EVERY instance of "MybbStuff_MyAlerts_AlertTypeManager::" or would that break something else? I swear this is the 2nd mod i've had to mod afterward lol
...This mod makes me need beer.
LINE 843 TOO, ALMOST SNEAKED PAST ME. WHEN GUEST QUOTES A POST !
(2015-07-30, 01:30 AM)SilentThief Wrote: [ -> ]Does this plugin need PHP 5.4?
It should work with later versions of PHP 5.3 I believe.
(2015-07-30, 03:06 AM)whyy Wrote: [ -> ]Okay I just took a deep breath...everythings fine. It's just a mod, and this is just myBB.
Now then. Have you tried having your mod enabled with guests posts?
I just got a fatal error that needs some looking at.
" Call to a member function getByCode() on a non-object in.... " in myAlerts.php
I'm somewhat shocked this was left unaddressed, myAlerts should not even be involved in guest posting,
Uninstalled until next release, please fix
(2015-07-30, 03:06 AM)whyy Wrote: [ -> ]Okay I just took a deep breath...everythings fine. It's just a mod, and this is just myBB.
Now then. Have you tried having your mod enabled with guests posts?
I just got a fatal error that needs some looking at.
" Call to a member function getByCode() on a non-object in.... " in myAlerts.php
I'm somewhat shocked this was left unaddressed, myAlerts should not even be involved in guest posting,
Uninstalled until next release, please fix
Fluoride sheeple rejoice!
Open up myalerts.php, and above line 891 AND 952 ADD
if ( !is_object( MybbStuff_MyAlerts_AlertTypeManager ) ) { return false; }
How long until the next error? Who knows. Author can i just add the above line right above EVERY instance of "MybbStuff_MyAlerts_AlertTypeManager::" or would that break something else? I swear this is the 2nd mod i've had to mod afterward lol
...This mod makes me need beer.
LINE 843 TOO, ALMOST SNEAKED PAST ME. WHEN GUEST QUOTES A POST !
Oops, I always forget about guest posting as I've never once used it. I'll have to add checks throughout the plugin for that, which I'll do for the next release.
Most people don't allow guest posting, so there are likely several mods that'll break.