I have designed the User Schema, but I am a bit confused about the User Shipping Address. The user might have many shipping addresses that he wants to save in his profile.
So I am a bit confused whether I should create a separate Address schema and refer the User inside or save the Array of the Address object directly in the User Schema. But, one problem I have noticed; If I save the address in the Address Array under User's Schema, I will not have an object ID for the Address to be identified that which address I want to get. In this situation, I will have to face the problem to update the address.
If someone can tell me how should I go, It will be helpful for me.
You don't need an object ID to do that task.
The solution is that you can just manually assign an id to each address
by just putting both id and address in a json document and then pushing it in the array of addresses.
it will look something like this after in json format
address : [
{
id:1,
address:"address 1"
},
{
id:2,
address:"address 2"
}
]
Related
I've been trying to implement live messaging in my application and I cannot seem to think of a convenient data structure inside Firestore. My current structure looks like this:
collection("conversations").document(id).collection("messages")
Each document holds two attributes user1 and user2 with nicknames of contributors to the conversation. Each document also owns a collection called messages which holds documents where each represents a single message sent with some info.
What I'm trying to do next is to check if the conversation already exists, if not then create it. The problem for me is write a correct query to find out if it exists.
My first idea was: create users array instead which holds nicknames of users and then simply query:
db.collection("conversations").whereField("users", in: ["username1", "username2"])
Problem with this is that it means "where users contains username1 OR username2", but I need it to contain "username1 AND username2".
I tried to be smart and chain the whereField function as following:
db.collection("conversations").whereField("users", arrayContains: "username1").whereField("users", arrayContains: "username2")
Turns out that you cannot use arrayContains more than once in a single query.
After that I came back to the structure as displayed on the screenshot with user1 and user2 and ran a new query:
db.collection("conversations").whereField("user1", isEqualTo: user).whereField("user2", isEqualTo: friend)
This query is ran in a function where user and friend are string parameters holding nicknames of both sender and receiver of the message we're currently sending. Imagine you are sending a message, user is always going to be your nickname and friend the receiver's one. The problem with the query is that you're nickname might be saved under user1 or user2 and receiver's nickname aswell. In either of those situations the conversation exists. How would I have to change the query since I don't know in an advance who will have which position in the query aswell as in Firestore. Running the last query that I included twice while switching user and friend parameter seems very unconvenient.
Any tips or solutions to progress in this problem will be much appreciated!
I have a general MongoDB question as I have recently found an issue with how I store things.
Currently, there is a collection called spaces like this:
{
_id: 5e1c4689429a8a0decf16f69,
challengers: [
5dfa24dce9cbc0180fb60226,
5dfa26f46719311869ac1756,
5dfa270c6719311869ac1757
],
tasks: [],
owner: 5dfa24dce9cbc0180fb60226,
name: 'testSpace',
description: 'testSpace'
}
As you can see, this has a challengers array, in which we store the ID of the User.
Would it be okey, if instead of storing the ID, I would store the entire User object, minus fields such as password etc?
Or should I continue with this reference path of referring to the ID of other documents?
The problem I have with this, is that when I want to go through all the spaces that a user has, I want to see what members are a part of that space (challengers array). However, I receive the IDS instead of name and email obviously. I am therefore struggling with sending the correct data to the frontend (I have tried doing some manual manipulation without luck).
So, if I have to continue the path of reference, then I will need to solve my problem somehow.
If it is okey to store the entire object in the array, It would be a lot easier.
HOWEVER, I want to do what is the best practice.
Thank you everyone!
In order to include information (like an order number) in a survey using an Email Collector, it's my understanding that this information needs to be stored in the Contact's custom variables. My concern is what happens if I am sending something like a customer satisfaction survey that needs to reference the order number, and the same customer (email address) places more than one order, and I have to send out more than one survey.
Will the custom values that are returned with the collectors/.../responses API call include the custom values at the time of the survey invite? Or will these be set to current values?
The custom values are stored on the response at the time the survey is taken. So if they change later, they will not change on the response. This will work fine as long as you don't sent out another survey with new custom values to the same contact before they respond to the previous one.
Just an FYI, there is also an option to set extra_fields on a recipient when adding recipients to an email collector (rather than on the contact).
POST /v3/collectors/<collector_id>/messages/<message_id>/recipients
{
"email": "test#example.com",
"extra_fields": {
"field1": "value1",
"field2": "value2"
}
}
I don't believe that data is stored with he response, but the recipient_id is and you can fetch the recipient by ID to get that data back.
Those are two options, you can see which one works best for you. The benefit of contact custom values is that you can view them and edit them from the web, whereas extra_fields are API only fields.
Given that an ABRecordID can change between cloud syncs and under other circumstances out of my control, how can I maintain a long-term reference to an IOS address book record?
Apple provides the following guidance:
"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."
But I don't understand this guidance. If the address book can have duplicate names in it AND since users can modify the name in a record how could this advice work?
For example, if the user modifies the name of an address book record my routine will fail to find it by ABRecordID so if I think search by the name hash I stored couldn't I find a duplicate name instead of the new ABRecordID for that specific record I previously referenced?
In the end, what is the BEST way to get a long-term reference to an IOS AddressBook record? And if the above advice really does work what am I missing?
The most robust (yet not completely failsafe) approach would be to come up with a priority ranking of ABRecord fields and store as much from that list as is available, along with the ABRecordID, into your own (hashed) private record format. When retrieving a private record (or at another convenient time), you can verify that the private record matches the ABRecord and work through a series of fallback checks to ensure it's accurate.
Example priority ranking:
ABRecordID
FirstName
LastName
PhoneNumber
ZipCode
When retrieving a record you can first match the ABRecordID. If that returns no results, you can do a search for FirstName + LastName. You can then match those results against PhoneNumber... etc. In this way you could potentially distinguish between 2 Bob Smiths, as they may have different phone numbers (or one may not have a phone number). Of course, depending on how long your priority list is, the more robust this mechanism will be.
The last resort would be prompting the user to distinguish between 2 Bob Smiths with brand new ABRecordID's whose records are otherwise identical -- after all, such an inconvenient prompt would be far more friendly than allowing the User to contact the wrong Bob Smith (and as I said, would be a last resort).
This solution for AB may involve some synchronization issues, however.
This is a familiar problem for anyone who has worked with the iOS Media Player. Specifically MPMediaItems in the User's Music Library have a property MPMediaItemPropertyPersistentID which the docs describe as:
The value is not guaranteed to persist across a sync/unsync/sync cycle.
In other words, the PersistentID is not guaranteed to be persistent. Solutions for this include doing similar fallback checks on MediaItem properties.
The RecordID only get changed either on delete or reset, when this is done all the new record(s) will have new createdProperty and modifiedProperty as well.
While I am reading the address book for the first time, I will save all entries of the record along with RecordID in my database.
I will save the last time the contacts synced from contacts to my database(name it something: lastSyncedTime) and store it some where.
I am done with syncing the contacts for the first time, now do the following for syncing anytime in future.
while Iterating through all records,
check createdTime(kABPersonCreationDateProperty) vs lastSyncedTime. If createdTime > lastSyncedTime, store the recordID in a "newRecords" NSArray.
If !(step 1) then check modifiedDate(kABPersonModificationDateProperty) vs lastSyncedTime. If modifiedDate > lastSyncedTime, then store the recordID in a "modifiedRecords" NSArray.
if !(1) && !(2) store all recordID in a "unModifiedRecords".
Now I will read all the contacts from my local database,
I will delete all local database records that are not find either in "modifiedRecords" or in "unModifiedRecords".
I will update all "modifiedRecords" in the local database.
I will create new records for all records in "newRecords".
Update the lastSyncedTime accordingly.
The documentation is communicating to you that you can't count on ABRecordID as a permanent identifier.
Consider this scenario: The user has a record for "Bob Smith". The user then deletes his "Bob Smith" record and then imports his contacts from his computer (creating a new ID) through iTunes sync.
So if you want to keep a permanent reference to an existing contact, you can keep a reference to the name and id as a hint that it is the same record you used before- but there is no real permanent reference.
If you keep a permanent reference to an address book contact, you must always be ready to deal with the fact that it may not be the same contact you used before.
Refer :
https://developer.apple.com/library/ios/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/DirectInteraction.html#//apple_ref/doc/uid/TP40007744-CH6-SW2
Clearly tells you how to handle it.
In many of my apps, it requires associating some data with a contact in addressbook. What I used to do is save the record id of an ABPerson and use that id to pull information upon each app launch. However, more and more I find that this approach is wrong because many times a user will use a service like mobileme where the addressbook is wiped and resynced. This causes the record id to change and all associations are lost. The user will have to go through each one and re-link them.
What is a better approach to holding a robust pointer to addressbook entries?
You should store three values: the record ID, the first name, and the last name.
1) In the case that the record ID hasn't changed, you're golden - just use that to locate the proper record.
2) If ABAddressBookGetPersonWithRecordID() does not locate a record for your stored record ID (it returns NULL), then you'll need to search the person records for a match based on the first and last name. You can drop down to using ABAddressBookCopyPeopleWithName() potentially or write your own locating code if you already have an array with all the person records in-memory. Locating the new record is up to you. Once to locate the new record, you can update your data storage with the new record ID.
Ultimately, you end up storing the record ID to use directly incase it doesn't change (if you're lucky) plus storing some keys from the address book entry that are unlikely to change. The name of the person or organization associated with an address book entry is most likely to change. You should, of course, account for the case where you may not find a record with the stored record ID or by searching for the name. This could trivially mean that the record was deleted, or it could mean that the record was renamed. You should handle that case whichever way you decide is best for your specific application.
I know this was last year, however, I thought I might suggest a method I use. The first time I ask the user to pick a contact (in order to associate certain of my app's private data with it) I then grab the record, create my own internal record id (the initials of the app name and a sequence number usually) modify the contact by adding a new ABRelatedName (type of "pref" name of "Other") value of my own internal record id. It looks like this in the .vcf
item3.X-ABRELATEDNAMES;type=pref:BZA101
item3.X-ABLabel:_$!<Other>!$_
That way, I can simply reference that record id when i add more data about the user such as the last time the app user contacted them, etc. Seems to work for me.
Hope that helps someone.
If the address book is indeed being completely wiped and re-loaded, and the only part that doesn't change is the display name, then storing the display name as the link seems like the only option.