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
store segment hash in DB #17408
store segment hash in DB #17408
Conversation
Hi @tsteur and @diosmosis, this is very WIP, but I'd like to know if I go in the right direction. A couple of questions I have:
sorry I have too many questions, I just'd like to understand more and do properly. thanks |
It shouldn't happen that the code is updated but DB is not updated. If it does happen, then it's because of a bug in the update process, or because of user error. So you shouldn't have to check if the added column exists. (There are exceptions in this because sometimes during the one click update, some new code will execute after it is written to the hard disk, while the old database hasn't been updated, but this shouldn't be one of those cases.)
Yes 👍 and updates are tied to a version, so first you'd bump the version in
Yes 👍 it should be initialized to
I think it depends on how this is implemented. To get rid of those urlencodes, in the
from what matt & thomas said, questions are to be encouraged 👍 |
I guess we don't have docs for writing updates/migrations, I'll put it on my list to try and write them (unless someone gets to them first). |
@tsteur and @diosmosis I'm wondering what else we need in this PR? |
core/Updates/4.3.0-b2.php
Outdated
$segmentTable = Common::prefixTable('segment'); | ||
$segments = Db::fetchAll('SELECT idsegment, definition from ' . $segmentTable); | ||
foreach ($segments as $segment) { | ||
$hash = md5(urlencode($segment['definition'])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be md5($segment['definition'])
. Apologies, I know I said it needs to be urlencode
d, I was referring to Segment construction. The Segment::getSegmentHash()
function decodes the definition before md5
-ing, so:
$segment = new Segment(urlencode($segment['definition']));
$hash = $segment->getHash();
is the same as
md5(urldecode(urlencode($segment['definition'])))
So if not going through Segment
, calling md5
directly works (but only for definitions in the segment table).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@diosmosis and @tsteur there is an issue with this one.
If we have a segment currently in a db like this actions%3E%3D2
, current Matomo version will use the hash of the urlencoded
version of it, so when we create the hash here:
$hash = md5($segment['definition']);
it won't be the same as we have in the archive_numeric
tables.
One solution would be using $hash = md5(urldecode($segment['definition']));
in the update file.
We don't support double encoded segments in the db, do we? Only in URL/API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The segment condition value is encoded multiple times, not the segment condition operator.
The hash is computed overall with the fully urlencoded segment, because that is what is sent in the segment
parameter. The stored segments are created by sending a definition=
parameter, which does not have special treatment and gets urldecoded once automatically. So there is a discrepancy with what is in the stored segment table and what is sent as a query parameter (segment=urlencode(pageUrl==urlencode(urlencode(segmentValue)))
. The hash in the table has to match the hash computed w/ the fully encoded segment. The tests should cover this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The hash that gets put in the table needs to be the same hash that is created in this test: https://github.com/matomo-org/matomo/blob/4.x-dev/plugins/SegmentEditor/tests/System/ApiTest.php#L21 when run on 4.x-dev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, @diosmosis, much more clear now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flamisz looks like that should work 👍 left some minor comments
Hi @diosmosis, can you please review it again (hopefully last time) and we can merge it then? |
When the tests pass, I'll take another look 👍 |
a63912e
to
2a1db98
Compare
This reverts commit 7e1d370.
…g/matomo into 17301-store-segment-hash-in-db
@flamisz @diosmosis was wondering if there's much left in this issue to do? Asking as we'd like to have this issue included in the next release |
Description:
fixes #17301
Review