Hi!
Dmitry Martynenko wrote:
> But I think it is axiom: less data and shorter keys -> more speed to SELECT.
Less data and good keys for executed queries -> more speed to SELECT. Just
making keys short will not improve speed. If there are a lot of records and key
is partial. MySQL will search da
Hi!
Mathias Schreiber [wmdb >] wrote:
> But the "amount of combinations" issue might be interesting to calculate.
> I am not sure if anyone has ever beaten the 1 billion marker, plus mysql
> itself might perform rather odd with tables this big, regardles of their
> content.
It is not just a numbe
Hi Dan,
>> But I think it is axiom: less data and shorter keys -> more speed
>> to SELECT.
DO> Sure, but the question is by how much. It doesn't matter that the look
DO> up is fast if it gives the wrong result. So its a trade off between
DO> accuracy and speed - and in this case I think accuracy
Hi Dmitry,
>> As far as cHash is concerned instead of doing an MD5 hash you could
>> simply do CRC32() in mysql.
DD> Yes, crc32 function also exists in the PHP. But I doubt that 32
DD> bits is enough for many possible combinations of URLs.
I think the same.
Unfortunately MD5 does not guarantee
> But I think it is axiom: less data and shorter keys -> more speed to
SELECT.
Sure, but the question is by how much. It doesn't matter that the look
up is fast if it gives the wrong result. So its a trade off between
accuracy and speed - and in this case I think accuracy takes priority.
Dan
Hi,
> Now I have tx_realurl_chashcache table like (it differs from standart
> RealURL table - spurl_hash already store full MD5 value):
>
> CREATE TABLE `tx_realurl_chashcache` (
> `spurl_hash` VARCHAR(32) NOT NULL DEFAULT '',
> `chash_string` VARCHAR(10) NOT NULL DEFAULT '',
> )
>
> If exte
Hi Dan,
DO> I think the 32 char value must be used, to prevent collisions and
DO> guarantee (almost) the uniqueness. How slow does it make the table
DO> seeks? And what table are we talking about - I think
DO> tx_realurl_chashcache only looks up by spurl_hash.
I write yesterday about it in anot
Dmitry Dulepov schrieb:
> Hi!
>
> Mathias Schreiber [wmdb >] wrote:
>> As far as cHash is concerned instead of doing an MD5 hash you could
>> simply do CRC32() in mysql.
>
> Yes, crc32 function also exists in the PHP. But I doubt that 32 bits is
> enough for many possible combinations of URLs.
I think the 32 char value must be used, to prevent collisions and
guarantee (almost) the uniqueness. How slow does it make the table
seeks? And what table are we talking about - I think
tx_realurl_chashcache only looks up by spurl_hash.
Dan Osipov
Calkins Media
http://danosipov.com/blog/
Dmitr
But is the hash unique & fast for lookups?
Dan Osipov
Calkins Media
http://danosipov.com/blog/
Dmitry Dulepov wrote:
> Hi!
>
> Dmitry Martynenko wrote:
>> Now I have tx_realurl_chashcache table like (it differs from standart
>> RealURL table - spurl_hash already store full MD5 value):
>>
>> CREA
Hi!
Mathias Schreiber [wmdb >] wrote:
> As far as cHash is concerned instead of doing an MD5 hash you could
> simply do CRC32() in mysql.
Yes, crc32 function also exists in the PHP. But I doubt that 32 bits is enough
for many possible combinations of URLs.
--
Dmitry Dulepov
TYPO3 core team
"So
Dmitry Dulepov schrieb:
> Hi!
>
> Mathias Schreiber [wmdb >] wrote:
>>> md5 provides uniqueness only if it is full 32-bit value. Using 16 bit
>>> will decrease probablity of conflict but will not eliminate it.
>> Why not use integers anyways?
>
> Integer as a URL hash?
As far as cHash is concern
Hi!
Dmitry Martynenko wrote:
> Now I have tx_realurl_chashcache table like (it differs from standart
> RealURL table - spurl_hash already store full MD5 value):
>
> CREATE TABLE `tx_realurl_chashcache` (
> `spurl_hash` VARCHAR(32) NOT NULL DEFAULT '',
> `chash_string` VARCHAR(10) NOT NULL DEF
Hi!
Mathias Schreiber [wmdb >] wrote:
>> md5 provides uniqueness only if it is full 32-bit value. Using 16 bit
>> will decrease probablity of conflict but will not eliminate it.
>
> Why not use integers anyways?
Integer as a URL hash?
--
Dmitry Dulepov
TYPO3 core team
"Sometimes they go bad. N
Hi Dmitry,
>>> May be better solution is to decrease key length - for example use 16
>>> byte (binary) MD5 value, instead of 32 chars value. In any case they are
>>> equal.
>>> Binary comparison is always faster then text comparison. Because text
>>> comparison also takes in account character set
Hi Dmitry,
>> May be better solution is to decrease key length - for example use 16
>> byte (binary) MD5 value, instead of 32 chars value. In any case they are
>> equal.
>> Binary comparison is always faster then text comparison. Because text
>> comparison also takes in account character sets and
Dmitry Dulepov schrieb:
> Hi!
>
> Dmitry Martynenko wrote:
>> May be better solution is to decrease key length - for example use 16
>> byte (binary) MD5 value, instead of 32 chars value. In any case they are
>> equal.
>> Binary comparison is always faster then text comparison. Because text
>> com
Already placed the order :)
Thanx for help
On 1/19/09 10:32 AM, "Dmitry Dulepov" wrote:
> Hi!
Tomaž Zaman wrote:
> One newbie question, if I build my own extension,
> extending pibase, do I
> need to use these Chashes with my links (links are
> mostly in listview,
> pointing to single view).
Hi!
Tomaž Zaman wrote:
> One newbie question, if I build my own extension, extending pibase, do I
> need to use these Chashes with my links (links are mostly in listview,
> pointing to single view). And if yes, why?
http://typo3bloke.net/post-details/linking_properly_in_your_typo3_code/
or buy t
Hi!
Dmitry Martynenko wrote:
> May be better solution is to decrease key length - for example use 16
> byte (binary) MD5 value, instead of 32 chars value. In any case they are
> equal.
> Binary comparison is always faster then text comparison. Because text
> comparison also takes in account chara
Tomaž Zaman schrieb:
> One newbie question, if I build my own extension, extending pibase, do I
> need to use these Chashes with my links (links are mostly in listview,
> pointing to single view). And if yes, why?
cHashes are used to bring a page into different "states".
Example:
Page 14 has an e
One newbie question, if I build my own extension, extending pibase, do I
need to use these Chashes with my links (links are mostly in listview,
pointing to single view). And if yes, why?
Thank you.
Tom
On 1/19/09 9:53 AM, "Dmitry Martynenko" wrote:
> Hi guys!
>
This is an extremely seri
Hi guys!
>>> This is an extremely serious issue for us, so I can write a patch. I
>>> don't know where to start though - so any guidance you can provide is
>>> appreciated.
>>
>> I am guessing >
>> http://www.typo3-unleashed.net/typo3apidocs/typo3api_4.2.0/html/d8/d11/class_8tslib__fe_8php-sour
Thanks!
I'll look into it.
Dan Osipov
Calkins Media
http://danosipov.com/blog/
Georg Ringer wrote:
> Dan Osipov wrote:
>> This is an extremely serious issue for us, so I can write a patch. I
>> don't know where to start though - so any guidance you can provide is
>> appreciated.
>
> I am gues
Dan Osipov wrote:
> This is an extremely serious issue for us, so I can write a patch. I
> don't know where to start though - so any guidance you can provide is
> appreciated.
I am guessing >
http://www.typo3-unleashed.net/typo3apidocs/typo3api_4.2.0/html/d8/d11/class_8tslib__fe_8php-source.htm
This is an extremely serious issue for us, so I can write a patch. I
don't know where to start though - so any guidance you can provide is
appreciated.
Dan Osipov
Calkins Media
http://danosipov.com/blog/
Dmitry Dulepov wrote:
> Hi!
>
> Georg Ringer wrote:
>> Dmitry, do you wanna do the patch?
Hi!
Georg Ringer wrote:
> Dmitry, do you wanna do the patch?
Not before February :(
--
Dmitry Dulepov
TYPO3 core team
"Sometimes they go bad. No one knows why" (Cameron, TSCC, "Dungeons&Dragons")
___
TYPO3-english mailing list
TYPO3-english@lists.netf
Dmitry Dulepov wrote:
> I am +1 to using longer cHash.
+1 because
- if no rewrite activated until know the url will just stay ugly
- if rewrite is used (cooluri, realurl, simualatestatic, whatever),
nothing will change (except less errors)
Dmitry, do you wanna do the patch?
Georg
_
Hi!
Dan Osipov wrote:
> We have a large installation, using TYPO3 4.2.3 and RealURL 1.5.2.
>
> In tx_realurl_chashcache we have duplicate cHash values corresponding to
> different spurl_hash values. As a result, links end up going to the
> wrong page. This is a serious flaw for a CMS!!
>
> What
We have a large installation, using TYPO3 4.2.3 and RealURL 1.5.2.
In tx_realurl_chashcache we have duplicate cHash values corresponding to
different spurl_hash values. As a result, links end up going to the
wrong page. This is a serious flaw for a CMS!!
What can be done to fix this? Can we i
30 matches
Mail list logo
