How to effectively store userkey in database?

mpahic's Avatar

mpahic

17 Jun, 2009 07:33 AM via web

Till now I stored the userkeys in mySQL in char(51) ascii general. This is to much unused space for hex number, and converting and parsing in php seems even slower. Does anyone have a better solution?

I also plan to switch to pgSQL because mySQL doesn't have some functions I need? Any thoughts on that? Because I'm not really familiar with defining atributes in postgre.

  1. Support Staff 2 Posted by Adam Kalsey on 17 Jun, 2009 07:42 AM

    Adam Kalsey's Avatar

    One of the great things about IMified is that we don't care what your
    back end is. Build it in php, cobol, or what ever and store the data
    in mysql, postgres, sqlite, or even Dbase. Doesn't matter to us.

    Userkeys are always a 35 character string (they're a 32-bit guid with
    some dashes in there as separators. You'd be safe reducing your field
    to 35 characters long.

  2. 3 Posted by mpahic on 17 Jun, 2009 02:03 PM

    mpahic's Avatar

    I just wanted to ask if some of the devs have a better solution.

    As for the string I'd like to convert it, but the dashes are problem and parsing them uses more time then entering the whole string.

  3. 4 Posted by Anthony Webb on 17 Jun, 2009 03:55 PM

    Anthony Webb's Avatar

    Help me understand why you are converting and parsing the userkey? I think storing it as a 35 character string is best.

  4. Anthony Webb closed this discussion on 17 Jun, 2009 03:55 PM.

  5. mpahic re-opened this discussion on 17 Jun, 2009 04:36 PM

  6. 5 Posted by mpahic on 17 Jun, 2009 04:36 PM

    mpahic's Avatar

    I'm not converting and parsing... my keys are always 51 characters long, and I'm receiving it in hex divided in four different parts. How can I receive it in 35 character string? Or simply converting it?

  7. Support Staff 6 Posted by Adam Kalsey on 17 Jun, 2009 04:47 PM

    Adam Kalsey's Avatar

    When we send a userkey, it looks like this: C1FA0AA3-BCB2-C5D8-76E488D728E7EA81

    We send a string formatted exactly like that, exactly 35 characters long.

  8. 7 Posted by mpahic on 19 Jun, 2009 11:09 AM

    mpahic's Avatar

    I really am stupid. Why didn't the word encoded cross my mind? Anyway thanks for the effort of trying to explain to me. Just one question: If I send the decoded key to your API will it work or do I have to use it the way it is received?

  9. 8 Posted by mpahic on 19 Jun, 2009 02:28 PM

    mpahic's Avatar

    Hm, something is not right. I'm getting some errors, and when I checked my userkey looked like this 0174D128535EE-2219-09D8-5434793CF1C5C2F2 (40 characters).

    I remember I had to expand the key (that is how I probably got to 51 -maybe by mistake). I tried to find the php function to pair the 32 bits, but unsuccessfully. That means I still have to store the key in 40 chars (or more). Storing it that way in database leaves a lot of unused characters since it only uses 0 to F and - sign.

  10. Support Staff 9 Posted by Adam Kalsey on 19 Jun, 2009 03:01 PM

    Adam Kalsey's Avatar

    Try changing your bot to say just this...

    `<?php
    print $_POST['userkey'];
    ?>`

    What do you see when you say something to it? You should get back the
    35 character userkey.

  11. 10 Posted by mpahic on 19 Jun, 2009 03:50 PM

    mpahic's Avatar

    Ok... also added to auto count: print $POST['userkey']."(".strlen($POST['userkey']).")"; and the result I got: 83D0C12853C08-2219-09D8-544099D22A9CACD1(40)

  12. Support Staff 11 Posted by Adam Kalsey on 21 Jun, 2009 05:31 PM

    Adam Kalsey's Avatar

    Interesting. The userkey in our database for that IM user is indeed 40 chars. Not sure how that happened.

  13. 12 Posted by System on 21 Jun, 2009 05:32 PM

    System's Avatar

    A Lighthouse ticket was created for this discussion

Reply to this discussion

Internal reply

Formatting help or Preview

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.