Hi all,
thank you for pointing us to this issue and for your ideas. We definitely
will discuss it with the product owner and let you know when it goes to our
backlog.
Have a nice weekend,
Vilma
-----Original Message-----
From: Sven Deichmann
Sent: Friday, April 19, 2013 3:07 PM
To: [email protected]
Subject: Re: [oxid-dev-general] Using base64 instead of md5 for seo idents?
Hi André,
not so fast :) That was only a guess, not an offical, fact based answer ;)
I said I could think of degraded performance as a result. Not that it has to
be that way.
To finally answer that point, I would need to make a request to the
developers.
Apart from that: go on ;)
Regards,
Sven
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von André
Herrmann
Gesendet: Freitag, 19. April 2013 13:24
An: [email protected]
Betreff: Re: [oxid-dev-general] Using base64 instead of md5 for seo idents?
Hi,
ok lets get rid of my entry suggestion of using base64. As noticed this
would harm performance so we should not consider this.
Altering anything in seo related tables is some kind of nightmare.
Anyone knows this who had to deal with tables 10 million entries up.
Well ok, altering oxseohistory should not be as worse as altering oxseo, so
having an extra column with the old address could work.
In the end the information will only be used for maintenance reasons I would
rather use an extra 1:1 table here which can be joined by OXOBJECTID if
needed.
If I go further thinking about this we still then have the problem that
there are already entries in oxseohistory which cannot be decoded and are
not maintainable.
A solution could be to track calls on oxseohistory table. If there is an
ident that matches, we should also know which seo address has been called
and are able to enter this one into the suggested column. This should help
recapturing lost seo-addresses. After some time we could
say: If there is still no text entry recaptured on the ident in
oxseohistory, it may be useless and the shop can get rid of it.
However, I'm glad to see, that most of you seem to agree the idea of making
this thing maintainable as most of you will have experience running into
trouble here as well ;-)
Regards,
André
On 19.04.2013 12:10, Robert Rosendahl wrote:
Hi,
why not just add an additional column to the database with the old url as
plain text (varchar(4096) or something like that)?
I guess using the md5 for searching is better perfomance-wise than
searching for some base64 encoded text. Base64 increases the length of the
data by about one third, while md5 uses a fixed length of 32 chars. And
since the urls will probably be longer than 32 chars this would be a
significant increase in size.
Of course, storing the url as plain text in addition to the hash would
increase the size of the database, but I guess space is not really a
problem (and the column wouldn't need an index).
Cheers,
Robert
-----Ursprüngliche Daten-----
Datum: 19.04.2013 11:58:40
Von: Kai Gazmaga <[email protected]>
An: <[email protected]>
Betreff: Re: [oxid-dev-general] Using base64 instead of md5 for seo
idents?
Vorgang: T-LUF3VO6IY9-91
Hi Guys,
here also great appreciation for making oxseohistory maintainable. We had
some issues with seo-links in the past and making it possible to see what
is in the DB would make things a lot easier.
Gruß, Kai
Am 19.04.2013 um 11:48 schrieb André Herrmann
<[email protected]>:
Hi Sven,
just wanted to discuss this thing here in the list to hear other
opinions, such as yours here, before making a feature request.
Yes you're right variable hash width could further slow down the
speed of oxseo, which indeed is not a good idea.
Maybe the "man-in-the middle" stuff should be implemented by
default, so that there is another table which stores seo-addresses to
their calls.
Or another solution could be to simply store oxstdlink and oxseolink
into oxseohistory.
The main goal of my approach is to make this thing maintainable.
Regards,
André
On 19.04.2013 11:34, Sven Deichmann wrote:
Hi André,
without having asked the shop team for reasons, only some wild guesses:
- base64 might blow up the amount of data stored
- md5 encoded links will probably all have a defined length, while
base64 is variable length
-> performance might decrease
Apart from that: file a feature request :)
(http://oxid.uservoice.com/)
Regards,
Sven
--
Sven Deichmann
Professional Services
Fon +49 761 36889-226
Fax +49 761 36889-29
www.oxid-esales.com
OXID eSales AG
Bertoldstraße 48
79098 Freiburg
Deutschland
Vorstand: Roland Fesenmayr (Vorsitzender), Andrea Seeger
Vorsitzender des Aufsichtsrats: Harald Fuchs, Sitz: Freiburg
Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866
-----Ursprüngliche Nachricht-----
Von: [email protected]
[mailto:[email protected]] Im Auftrag von
André Herrmann
Gesendet: Freitag, 19. April 2013 11:12
An: [email protected]
Betreff: [oxid-dev-general] Using base64 instead of md5 for seo idents?
Hi folks,
due oxseohistory table is a growing blackbox, wouldn't it make sense to
use base64_encode instead of md5 for generating idents in seo table?
This would make it easy to make historical links visible because there
is a decode function for this.
In current oxseohistory table, the only possibility to get the former
SEO-Links is to play "man in the middle" and track and store any call
that goes to oxseohistory.
Would you generally agree with my suggestion to use base64 instead
of
md5 for seo idents or do you see any problems here?
Greetings,
André
--
André Gregor-Herrmann
Entwicklung, Administration, Projektmanagement
mail [ [email protected] ]
web [ www.fatchip.de ]
FATCHIP [ GmbH ] | sitz [ Helmholtzstrasse 2-9 | 10587 Berlin ]
| fon [ 030.39 88 93 51 ] | fax [ 030.39 88 93 52 ] | mail [
[email protected] ] | Ust-Id. [ DE 265567757 ] | Amtsgericht
[ Berlin-Charlottenburg ] | HRB [120567 B] | Geschäftsführung [
Dipl.-Ing. Hendrik Bahr ]
Be Smart, Go Green. Don't print this email unless you really need to.
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
--
André Gregor-Herrmann
Entwicklung, Administration, Projektmanagement
mail [ [email protected] ]
web [ www.fatchip.de ]
FATCHIP [ GmbH ] | sitz [ Helmholtzstrasse 2-9 | 10587 Berlin ] | fon
[ 030.39 88 93 51 ] | fax [ 030.39 88 93 52 ] | mail [
[email protected] ] | Ust-Id. [ DE 265567757 ] | Amtsgericht [
Berlin-Charlottenburg ] | HRB [120567 B] | Geschäftsführung [ Dipl.-Ing.
Hendrik Bahr ]
Be Smart, Go Green. Don't print this email unless you really need to.
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________
dev-general mailing list
[email protected]
http://dir.gmane.org/gmane.comp.php.oxid.general
