When saving an object in Propel2 is it guaranteed to have ID in postSave?
I'm having trouble finding an answer to this.
Related
Outlook COM has a method under Application.Session.GetAddressEntryFromID method to grab an address entry without having to iterate through the entire Global or All Users address book.
The issue is it is expecting the ID that an entry has under the AddressLists object.
In Active Directory, there is no equivalent that gives me the same GetAddressEntryFromId string.
I was previously making a list of all users, minus rooms and resources, by going through the entire COM object, but that takes too long; 20mins.
I figured if I use AD, which is faster, with filters to find the users, then I can grab the GUID and when looking for info on the user, not have to go through the entire COM object to grab it, but it will happen locally to the executable being run.
The issue I am having, as an example, is that I have a user with the following ID;
00000000DCA740C8C042101AB4B908002B2FE18201000000000000002F6F3D45766572657374205265696E737572616E63652F6F753D436F72702D48512F636E3D526563697069656E74732F636E3D6A6E6700
In AD the msExchMailboxGuid has a value of
{4A49BD1C-62AE-4674-B097-C06528BDBEAE}
Not sure if these are the same, but I need to learn to better save it.
What else can I use, what can I do with the current time?
GAL entry id is constructed from the EX address (which is stored in the legacyDN attribute).
The entry id you have above contains the following:
I'm maintaining a small program that goes through documents in a Neo4j database and dumps a JSON-encoded object to a document database. In Neo4j—for performance reasons, I imagine—there's no real data, just ID's.
Imagine something like this:
posts:
post:
id: 1
tags: 1, 2
author: 2
similar: 1, 2, 3
I have no idea why it was done like this, but this is what I have to deal with. The program then uses the ID's to fetch information for each data structure, resulting in a proper structure. Instead of author being just an int, it's an Author object, with name, email, and so on.
This worked well until the similar feature was added. Similar consists of ID's referencing other posts. Since in my loop I'm building the actual post objects, how can I reference them in an efficient manner? The only thing I could imagine was creating a cache with the posts I already "converted" and, if the referenced ID is not in the cache, put the current post on the bottom of the list. Eventually, they will all be processed.
The approach you're proposing won't work if there are cycles of similar relationships, which there probably are.
For example, you've shown a post 1 that is similar to a post 2. Let's say you come across post 1 first. It refers to post 2, which isn't in the cache yet, so you push post 1 back onto the end of the queue. Now you get to post 2. It refers to post 1, which isn't in the cache yet, so you push post 2 back onto the end of the queue. This goes on forever.
You can solve this problem by building the post objects in two passes. During the first pass, you make Post objects and fill them with all the information except for the similar references, and you build up a map[int]*Post that maps ID numbers to posts. On the second pass, for each post, you iterate over the similar ID numbers, look up each one in the map, and use the resulting *Post values to fill a []*Post slice of similar posts.
I never quite understood the if needed part of the description.
.fetchAll()
Fetches the given list of Parse.Object.
.fetchAllIfNeeded()
Fetches the given list of Parse.Object if needed.
What is the situation where I might use this and what exactly determines the need? I feel like it's something super elementary but I haven't been able to find a satisfactory and clear definition.
In the example in the API, I notice that the fetchAllIfNeeded() has:
// Objects were fetched and updated.
In the success while the fetchAll only has:
// All the objects were fetched.
So does the fetchAllIfNeeded() also save stuff too? Very confused here.
UPDATES
TEST 1
Going on some of the hints #danh left in the comments I tried the following things.
var todos = [];
var x = new Todo({content:'Test A'}); // Parse.Object
todos.push(x);
x.save();
// So now we have a todo saved to parse and x has an id. Async assumed.
x.set({content:'Test B'});
Parse.Object.fetchAllIfNeeded(todos);
So in this scenario, my client x is different than the server. But the x.hasChanged() is false since we used the set function and the change event is triggered. fetchAllIfNeeded returns no results. So it isn't that it's trying to compare this outright to what is on the server to sync and fetch.
I notice that in the request payload, running the fetchAllIfNeeded is sending the following interesting thing.
{where: {objectId: {$in: []}}, _method: "GET",…}
So it seems that on the clientside something determines whether an object isNeeded
Test 2
So now, based on the comments I tried manipulating the changed state of the object by setting with silent.
x.set({content:'Test C'}, {silent:true});
x.hasChanged(); // true
Parse.Object.fetchAllIfNeeded(todos);
Still nothing interesting. Clearly the server state ("Test A") is different than clientside ("Test C"). and I still results [] and the request payload is:
{where: {objectId: {$in: []}}, _method: "GET",…}
UPDATE 2
Figured it out by looking at the Parse source. See answer.
After many manipulations, then taking a look at the source - I figured this out. Basically fetchAllIfNeeded will fetch models in an array that have no data, meaning there are no attribute properties and values.
So the use case would be you have lets say a parent object with an array of nested Parse Objects. When you fetch the parent object, the nested child objects in the array will not be included (unless you have the include query constraint set). Instead, the pointers are sent back to clientside and in your client, those pointers are translated into 'empty' models with no data, basically just blank Parse.Objects with ids.
Specifically, the Parse.Object has an internal Boolean property called _hasData which seems to be toggled true any time stuff like set, or fetch, or whatever gives that model attributes.
So, lets say you need to fetch those child objects. You can just do something like
var childObjects = parent.get('children'); // Array
Parse.Object.fetchAllIfNeeded(childObjects);
And it will search for those children who are currently only represented as empty Objects with id.
It's useful as opposed to fetchAll in that you might go through the children array and lazily load one at a time as needed, then at a later time need to "get the rest". fetchAllIfNeeded essentially just filters "the rest" and sends a whereIn query that limits fetching to those child objects that have no data.
In the Parse documentation, they have a comment in the callback response to fetchAllIfNeeded as:
// Objects were fetched and UPDATED.
I think they mean the clientside objects were updated. fetchAllIfNeeded is definitely sending GET calls so I doubt anything updates on the serverside. So this isn't some sync function. This really confused me as I instantly thought of serverside updating when they really mean:
// Client objects were fetched and updated.
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
I need to reference ABPerson records from within an application. I use the unique ID provided by
- (NSString *)uniqueId
and attach it to my in-app contact record.
Additionally, I save ABPerson's vCardRepresentation as a fallback. In case the app isn't any longer able to locate the ABRecord using the uniqueID, the app asks the user to recover the adressbook record using the saved vCardRepresentation. All works fine.
Unfortunately, a friend told me, that uniqueId isn't immutable: During a sync, uniqueId may suddenly change.
According to him, somewhere in iOS documentation, Apple explains that no way exists to immutable identify ABPersons using uniqueId. In OS X' Cocoa documentation, I failed to find such a hint.
On a given Mac, may the uniqueId change suddenly? If that's true, what's the correct way to identify ABPerson records from within an external application?
In case the uniqueID isn't immutable, I certainly may assign a custom property with a GUID. Unfortunately, custom fields do not sync.
Certainly, I'd prefer to use uniqueId.
For whats its worth, from Apple's techdoc:
kABUIDProperty
The unique ID for this record. It’s guaranteed never to change, no matter how much the record changes. If you need to store a reference to a record, use this value. Type: kABStringProperty.
Available in Mac OS X v10.2 and later.
Declared in ABGlobals.h.
It looks like the kABUIDProperty approach might not work anymore. I came across this blog entry with more discussion in the comments at: http://blog.clickablebliss.com/2011/11/07/addressbook-record-identifiers-on-mac-and-ios/.
A case in point: If a user decides to turn on iCloud sync, the unique ids in that user's address book will change. If the users turns off iCloud sync, they'll change again.
Addendum: it might be worthwhile looking at the StackOverflow entry here.
Apple's docs do say this (quoted from the link):
"The recommended way to keep a long-term reference to a particular record is to store the
first and last name, or a hash of the first and last name, in addition to the identifier.
When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record."