Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE:
Mark,
wouldn't it be better to keep the bitmaps separate than merge? You could have upper 8 bits for storage bitmap and lower 8 bits for permissions.
Raj
-----Original Message-----
Sent: Tuesday, January 06, 2004 5:34 AM
To: Multiple recipients of list ORACLE-L
Hi Stephane,
I of course simplified the problem a bit. However, the bitmaps are actually artificial entities which I'm building up from some underlying tables and some clever indexing schemes. The problem is, I don't have total data model control, and the permissions and storage info are stored in two different tables. Through some clever indexing and views, I'm presenting two different bitmap views. The idea is I can do a unique lookup on storage, a unique lookup on permissions, and then AND them together and provide a resultant bitmap, availability. The front-end app will then use that availability bitmap to decide what options to present to the end-user. The problem is the heterogeneous nature of the two bitmaps.
Finally, I'm fully utilizing the bitspace I have, because the 2 bits for permission represent two different (and independent) pieces of info. In the example you provide below, there is no way to express P1 AND P2 with storage. In other words, my permissions matrix looks like:
00 - No permissions 01 - Permission for user to acquire doc via email 10 - Permission for user to acquire doc via on-line viewing 11 - Permission for user to acquire doc via email or on-line
Note that the bitmap is full, and storage has not entered into the picture yet. So, Storage will say either 0, not stored or 1, stored.
I need to AND the permissions and the storage. But, I need to AND the single bit storage with two bits of permissions.
Does that make more sense?
-Mark
-----Original Message-----
From: Stephane Faroult [mailto:sfaroult_at_oriolecorp.com] Sent: Tue 1/6/2004 5:13 AM To: Multiple recipients of list ORACLE-L Cc: Subject: RE:
This is what spontaneously comes to my mind and may not make a lot of sense in your case, but why do you need TWO bitmaps in the first place? Your second (Permission) bitmap uses 2 bits to store three states (no permission/P1/P2). This is enough to hold the STORAGE information as well, eg
00 Not stored 01 Stored with no permission 10 Stored with P1 11 Stored with P2
HTH, SF
>----- ------- Original Message ------- -----
>From: "Bobak, Mark" <Mark.Bobak_at_il.proquest.com>
>To: Multiple recipients of list ORACLE-L
><ORACLE-L_at_fatcity.com>
>Sent: Tue, 06 Jan 2004 01:39:25
>
>Hi,
>
>Well, since I can't sleep, I may as well try
>solving a problem.
>
>This is a bit odd, and I'm trying to think of the
>most efficient way to do
>it. I've set up some bitmaps in my app. Consider
>we have documents that
>we want to sell. In order to be able to sell a
>given doc, we need to have it
>stored in the vault and we also need to have
>negotiated the proper contract
>w/ the publisher. So, I've got two bitmaps,
>STORAGE and PERMISSIONS.
>
>But, here's the hook. There are 8 different types
>of storage, so I have
>an 8 bit mask. However, for every storage type,
>there are two types of
>permission. So, I have a 16 bit permissions mask.
>
>What I'd like to do is take my 8-bit STORAGE mask,
>say it's 10110011
>and convert it to 1100111100001111. Note that all
>I did there was take
>each bit in the input mask, and make the same value
>repeat. So, 0 would
>become 00, 1 would become 11, 10 would become 1100.
> Does that make sense?
>Once I've done that, I can take my STORAGE mask
>that's now stretched to 16
>bits, and directly AND it with my PERMISSIONS mask.
>
>
>So, my question is: Is there a nice, scalable way
>to take my 8 bits and
>expand them into 16 bits, in the way that I'm
>describing? A clever bit
>twiddling expression would be perfect, but anything
>that's efficient and
>scalable will do. (The end product will be hidden
>behind a view or stored
>procedure.)
>
>Any thoughts, anyone?
>
>Thanks in advance,
>
>-Mark
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephane Faroult INET: sfaroult_at_oriolecorp.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Bobak, Mark INET: Mark.Bobak_at_il.proquest.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jamadagni, Rajendra INET: Rajendra.Jamadagni_at_espn.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Tue Jan 06 2004 - 05:24:25 CST
![]() |
![]() |