| Author |
Message
|
| KoGor |
 Posted: Thu Jan 10, 2013 6:45 am Post subject: Access to the specific byte or bit of a BLOB variable |
 |
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
Hi all!
My task is to develop an authorization message flow on WMB. This message flow has to check message sender rights in database and if there is a rule, that allows him to send messages to the message recipient, forward this message into a routing flow.
I want to encode an authorization string for each user, where each bit is sequential number of user. A '1' in bit position means than this user is allowed to send messages to the user with this sequential number.
For example, there are three user.
user1 has sequential number 1 and it will be the first bit of the string.
user2 has sequential number 2 and it will be the second bit of the string.
user3 has sequential number 3 and it will be the third bit of the string.
So each user can send messages oneself so there will be a '1' in his own position.
User1 can send messages to user2 but can not to user3. Then the authorization string for him will be '110'
User2 can send messages to user3 but can not to user1. Then the authorization string for him will be '011'
User3 can send messages to user1 and user2. Then the authorization string for him will be '111'
It's very tempting to encode this string into something smaller for example into integer. But as soon as the number of users is not limited I can not use integer type. I wanted to use BIT type to create the string and then convert it to the BLOB to save memory and database space. I wanted to store this BLOB string in DB2 as binary VARCHAR. Then I can read this string from database as blob object into a broker and work with its bytes. And compare each byte with BITAND to find out if users are allowed to communicate. But then I realize that I cannot find a way to address to each BLOB's byte or bit. It's possible if a message parsed by BLOB parser http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ac11640_.htm?resultof=%22%42%4c%4f%42%22%20%22%62%6c%6f%62%22%20 but it won't work for variables. And also I found that there is a limited by 2^63 to convert BIT to BLOB (http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/topic/com.ibm.etools.mft.doc/ak05680_.htm)
Now I don't see any option except store this authorization string as plain character in DB and work with each character with SUBSTR. Somesthing like:
| Code: |
WHILE i<=LENGTH(SenderAuthString) DO
IF (SUBSTRING (SenderAuthString FROM i FOR 1) = '1') AND (SUBSTRING (ReceiverAuthString FROM i FOR 1) = '1') THEN
SET i = LENGTH(SenderAuthString);
SET Result = true;
END IF;
SET i = i+1;
END WHILE; |
But actually I think this is an awful slow solution. Is there way to do it a better way? Any idea?
Thank you in advance! |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Thu Jan 10, 2013 7:13 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| McueMart |
| Posted: Thu Jan 10, 2013 7:27 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
You can store the data as a blob in db2, but you would need to cast from BLOB to BIT to have the data in the format you want it (i.e. a sequence of 0's and 1's). You can then use SUBSTRING on your BIT variable (I would expect..).
Sounds to me like you might be trying to over engineer this a little bit as the TINY performance/storage gain you'll achieve using bitwise operations is not worth the added complexity. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 10, 2013 7:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| McueMart wrote: |
| Sounds to me like you might be trying to over engineer this a little bit as the TINY performance/storage gain you'll achieve using bitwise operations is not worth the added complexity. |
Also, SUBSTRING works just fine on BLOB datatypes as well.
Also, if you were using v8, you could use DFDL to model bit-level fields and parse the blob into a logical message tree and test to see if a name existed/had a value in the tree.... |
|
| Back to top |
|
|
| KoGor |
| Posted: Thu Jan 10, 2013 8:14 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
| McueMart wrote: |
You can store the data as a blob in db2, but you would need to cast from BLOB to BIT to have the data in the format you want it (i.e. a sequence of 0's and 1's). You can then use SUBSTRING on your BIT variable (I would expect..).
|
Unfortunately there's a limit for casting between BLOB and BIT as I wrote it must not be larger than 2^63. So an authorization string can be stored as BLOB or CHARACTER in DB and broker. I don't see difference between them in my case. So it seems simpler to store as plain text in DB and broker variables as it will be the same size. |
|
| Back to top |
|
|
| KoGor |
| Posted: Thu Jan 10, 2013 8:16 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
| mqjeff wrote: |
Also, if you were using v8, you could use DFDL to model bit-level fields and parse the blob into a logical message tree and test to see if a name existed/had a value in the tree.... |
Thanks! I will read about DFDL. May be it is time to migrate to v8. But the time I tried to use v8 it was useless. Some major features were not working at all. I hope it's fixed now.
Last edited by KoGor on Thu Jan 10, 2013 8:31 am; edited 2 times in total |
|
| Back to top |
|
|
| McueMart |
| Posted: Thu Jan 10, 2013 8:34 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| I wrote it must not be larger than 2^63 |
I dont really see how this is an issue unless you have more than 9223372036854775808 users for some reason??
| Quote: |
| I don't see difference between them in my case. So it seems simpler to store as plain text in DB and broker variables as it will be the same size |
Im not disagreeing with you that it seems simpler to store it as character (VARCHAR) data in the DB, but there is a difference and they wont be the same size. If you have 32 users and you want to store them as plain text, this will take 32 characters (i.e. 32 bytes assuming ASCII). If you are using your binary encoding method it would only take 4 bytes. |
|
| Back to top |
|
|
|
|
