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

improve boards category parse_bbc fixes #5734 #5736

Draft
wants to merge 1 commit into
base: release-2.1
from

Conversation

@albertlast
Copy link
Collaborator

commented Jul 12, 2019

the base idea is to build the best of two worlds,
on the one hand being able to modify the category name/description and board name/dscription with bbc,
on the other hand being fast to allow big board run in the same speed like small one.

since we do db changes in the process,
we can do a mutch better work on upgrade process check if the changes needs to run or not.

missing:
upgrade process is not final
edit logic is missing

issue: #5734

improve getboards parse_bbc
Signed-off-by: albertlast albertlast@hotmail.de

@albertlast albertlast changed the title improve boards category parse_bbc improve boards category parse_bbc fixes #5734 Jul 12, 2019

@jdarwood007

This comment has been minimized.

Copy link
Member

commented Jul 13, 2019

This won't work reliably because parse_bbc can have language strings. We already cache the board index under certain conditions which is what is needed here.

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 13, 2019

Than we should allow the admin to disable parse_bbc for board and catagory name/description?
In my eyes is the feature not worth that it raise the runtime by 5x (with optimization its double the time).

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 14, 2019

Or would be not better to ban this tages for description and name,
so that the display version is language undepend?

@sbulen sbulen added the Performance label Jul 14, 2019

@live627

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

Use the cache sub system for this.

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 16, 2019

Show me that is faster or go away with this solution.

@Sesquipedalian

This comment has been minimized.

Copy link
Member

commented Jul 17, 2019

I'm not going to merge anything that changes the structure of the boards table at this stage.

However, @albertlast is right that it is silly to cache and retrieve each board name and description separately. We should be able to improve performance if we cache the parsed board names and descriptions all at once in a single array.

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 17, 2019

Since the user based on the right see different part of the forum I'm not sure how well this works.
But we could save the original and display version in same columns by using json encoding,
Would imply that we would extend the size of names columns,
Since the description already are text would be here no change needed.

Would this a solution too?

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 22, 2019

@Sesquipedalian i wait on a comment from you.

@Sesquipedalian

This comment has been minimized.

Copy link
Member

commented Jul 23, 2019

My idea will work if we follow this order:

  1. Retrieve the array of parsed board names and descriptions from the cache.
  2. Loop through the user's board tree and either:
    a. Get and use the existing parsed value from the cached array if it exists, or
    b. Run parse_bbc to generate the parsed value, use it for display, and append it to the big array of parsed values.
  3. When done looping through the board tree, if we appended anything to the array of parsed values, save the new version of the array to the cache.

This method ensures that we only need to parse each board's name and description once, and it also spreads out the workload among multiple users, since the initial parsing for each board only happens when needed.

I think this will be a better approach, especially in the RC stage when we want to avoid database alterations except when absolutely necessary.

@albertlast

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 23, 2019

I see some problem because the description is a text fields,
which mean it got unlimted size,
so every description can be very big when you combind them into one array you big array get realy big...

But when i take your idea i could imagine a "middle" way.
We could save the name in "big array" and the descirption since they are text column,
we could save ther the parse value directly by side in the same column of the orginal value by using json encode or something similiar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.