crc32 guid doesn't work

crc32 is a function that generates a unique integer given a string.

If you have two string guids that are generating the same CRCs then please provide them here.

New releases of 4.7 & 5 have been published, If it's at all possible to let go of your already aggregated items, I advise *you alone* to disable then uninstall the aggregation module before re-installing this version. But most importantly, BACKUP first :-)

The only reason I advise you to do this is to clean the tables from the many bogus guids, if the data is critical and you don't mind wrong guids for these items then you can update without uninstalling.

Thanks for reporting this critical bug, please let me know if this solved your problem ASAP.

reopen after 5.x-2.8. maybe storing crc32 as string in hex will help?

download new release and give it another go.

in 2.10 there are lack of closing bracket in line 779. After adding it, it's working.

typo fixed, that's what you get for staying up late ;-)

I was too fast claiming its working...
on 32-bit architecture I have:

guid: http://www.manga.gildia.pl/newsy/archiwum/2007/04/usagi-jak-sin-city-i-300
CRC of guid: 2434694407
guid in database: 2147483647

I have more entries with 2147483647 in database and after removig nodes their recreate. So still there is a bug...

it seems crc32 wasn't good to chose...
See this: http://bugs.php.net/bug.php?id=39062

Maybe consider replacing crc32 with sha1 or md5? They don't have such a bug...

Did you run the update script on the machine you're testing on?

I'm aware of the crc32 bug, both sha1 and md5 generate strings and I want to avoid database string comparisons to boost speed, the error you're reporting seems to be suggesting that the story_guid & image_guid are still signed ints, the last update hook I provided should convert them to unsigned ints. Please run update.php and let me know what happens.

to be sure:
I downloaded once again ver. 2.11
I ran update.php
I deleted all aggragation_item nodes to be sure there are no old crcs
I run cron.php to collect my feeds

As the result:
feed1 - 20 items in feed - 13 imported, there is guid = 2147483647
feed2 - 10 items in feed - 6 items imported, there is guid = 2147483647
feed3 - 10 items in feed - 6 items imported, there is guid = 2147483647

every guid in database is less than 2147483647... There wasn't any problems with versions prior 2.6. on 32bit systems.

BTW I don't think speed boost you get by using numbers instead of strings are noticable. Mysql is fast enough to compare hundets of strings in miliseconds and fid is nicely narrowing serches.

Could you please check the database schema after running update? (it's update #4)

show create table aggregation_item;

Both story_guid & image_guid should have been converted from "int signed" to "int unsigned" during the update. I've tested it and it worked locally.

In my database everything was ok, guid is unsigned int. After some more testing I found that the problem is in Drupal's db_query function. If you pass arguments by %d Drupal converts numbers to internal int which in PHP is always signed. That caused numbers bigger than max_int were converted to 2147483647. If you let database to handle the conversion by passing guid by %s, everything woks great.
This has very small influence on DB because the conversion is made in first place and searching is done with numbers.

BTW If you care about performance consider new index on 2 fields (fid, guid) it gives you more boost than 2 indexes on single columns.

Thanks. I've created 4.7 & 5 releases and changed all guid related queries from %d to %s, I've sent you an email with my MSN and qnext account numbers, did you get it? Thanks again.