The spec for pst mentions that the name-id-map is one per pst.
This map may contain several pidlid properties as defined in their spec MS-OXPROPS, but from the looks of it most of these pidlid properties appear to be message specific.
How are properties for each message stored/managed in this name-id-map ?
No, the messages store the 4 byte property tags. E.g. PR_SUBJECT_A (which is not a named property and hence does not need to be mapped) is 0x0037001E.
The map is needed only if a client calls IMAPIProp::GetIDsFromNames and IMAPIProp::GetNamesFromIDs. In the former case, you get the GUID and the id (either string or an int) and you need to lookup the 4 byte (or rather 2 bytes since the lower 2 bytes are prop type) prop tag corresponding to that GUID/id combination. In case of GetNamesFromIDs, you do reverse lookup - given the prop tag, return the GUID/id.
Related
RocksDBStore<K,V> stores keys and values as byte[] on disk. It converts to/from K and V typed objects using Serdes provided while constructing the object of RocksDBStore<K,V>.
Given this, please help me understand the purpose of the following code in RocksDbKeyValueBytesStoreSupplier:
return new RocksDBStore<>(name,
Serdes.Bytes(),
Serdes.ByteArray());
Providing Serdes.Bytes() and Serdes.ByteArray() looks redundant.
RocksDbKeyValueBytesStoreSupplier is introduced in KAFKA-5650 (Kafka Streams 1.0.0) as part of KIP-182: Reduce Streams DSL overloads and allow easier use of custom storage engines.
In KIP-182, there is the following sentence :
The new Interface BytesStoreSupplier supersedes the existing StateStoreSupplier (which will remain untouched). This so we can provide a convenient way for users creating custom state stores to wrap them with caching/logging etc if they chose. In order to do this we need to force the inner most store, i.e, the custom store, to be a store of type <Bytes, byte[]>.
Please help me understand why we need to force custom stores to be of type <Bytes, byte[]>?
Another place (KAFKA-5749) where I found similar sentence:
In order to support bytes store we need to create a MeteredSessionStore and ChangeloggingSessionStore. We then need to refactor the current SessionStore implementations to use this. All inner stores should by of type < Bytes, byte[] >
Why?
Your observation is correct -- the PR implementing KIP-182 did miss to remove the Serdes from RocksDBStore that are not required anymore. This was fixed in 1.1 release already.
The header file CoreAudio/AudioHardware.h refers to a class "AudioBox" and indicates that it is distinct from but related to the class "AudioDevice". Searching developer.apple.com yields no hits for AudioBox. There is, unfortunately, a commercial product called AudioBox™, which makes googling for the term painfully low-yield.
Here are the comments containing the references:
kAudioHardwarePropertyBoxList
An array of AudioObjectIDs that represent all the AudioBox
objects currently provided by the system.
kAudioHardwarePropertyTranslateUIDToBox
This property fetches the AudioObjectID that corresponds to the
AudioBox that has the given UID. The UID is passed in via the qualifier as a CFString while the AudioObjectID for the AudioBox is
returned to the caller as the property's data. Note that an error
is not returned if the UID doesn't refer to any AudioBoxes.
Rather, this property will return kAudioObjectUnknown as the value of the property.
The header file: AudioHardwareBase.h contains numerous references to AudioBox, but does not define or explain it, although it associates it with AudioDevice.
Searching the docs via XCode just takes me back to AudioHardwareBase.h.
I can infer that perhaps an "AudioBox" is an audio device that is accessed via a plugin. But this does not appear to be stated anywhere.
So What Is An AudioBox?
An AudioBox is a container of (usually) AudioDevices
Have come across a scenario where using Outlook Spy I can see that my msg has the above said property. But once i export the pst and try to extract this message, this property does not exist in the expecte location i.e. 0x0001 index and offset 0x0040.
However in outlook spy i see a tag num of 0x80B00040 and sure enough when I look at the property mappings i see in tag 0x80B0 i.e. this value.
My question is that where does this tag value come from ? I do not find any references to it here http://msdn.microsoft.com/en-us/library/ee237112(v=exchg.80).aspx ?
Can someone also explain the relation between named property and tags ?
What do you mean by "this property does not exist in the expecte location i.e. 0x0001 index and offset 0x0040."?
Do you mean the property tag changes? This is to be expected - the mappings between GUID//id and the prop tag are store specific. You should always call IMAPIProp::GetIDsFromNames on an object from the desired store to figure out the property tag.
Giving a quick overview of my situation:
I am working on an N-Tier app that relies a lot on serialization, objects interact with the database mainly in a serialized fashion, objects and collections are inserted, updated and read as XML from within stored procedures.
For some of the smaller data classes I am simply using ExecuteNonQuery, Reader, etc to interact with the data, as its easier, but I have encountered a problem.
Data is inserted into the database using ExecuteNonQuery, using Parameters - some of the data inserted are properties that are Enums (stored in the DB as ints) that have the FlagAttribute attached. On a Enum such as:
<Flags()> _
Public Enum Fruit As Integer
<Description("None"), XmlEnum("0")> None = 0
<Description("Apple"), XmlEnum("1")> Apple = 1
<Description("Banana"), XmlEnum("2")> Banana = 2
<Description("Orange"), XmlEnum("4")> Orange = 4
End Enum
The value read back might be an Integer value of 1, 3, 7, etc, and inserted into the database not using serialization, when it is read back however as part of a larger group of classes using the ExecuteXmlReader (filling a XmlReader object) and then needing to be deserialized, it can not be, as 7 for example, causes 'Instance validation error: '7' is not a valid value for Fruit', as it is expecting it to be serialized in the format of:
<fruitOptions>1 2 4<fruitOptions>
All in all it is a little confusing, and I could probably work around it by storing it in the database in the 1, 2, 4 format, but sadly not in the int type that it currently is in.
Does anyone have any ideas on this?
You're going to have to ask your DBA or the author of the stored procedure you're using. It appears they've specified that this field is not an enum, but rather a list.
I have a core data model with a variety of properties. For some reason the string properties are limited to 50 characters even though no max value (or default value for that matter) is set.
Interesting thing is that it was fine before I added fetch requests using the browser view of the data model.
Any thoughts? Thanks!
How are you validating that the length is 50?
if you print the object in gdb, you'll only see the first 50 by default.
from what I've observed, the debugDescription method for an NSManagedObject prints out 50 or 51 characters when you po managedObjectInstance
I've found that in in gdb, do a po [managedObject valueForKey:#"attribName"] will return the whole string.
Not sure if the fetch request has anything to do with it.