I'm making a game involving the user's contacts, but need a way to uniquely identify each contact. This is because the user can easily change the name, phone number, or other property of a given contact. Is there a way to do this?
You can use ABRecordGetRecordID() to get the unique ID of a record. It returns an ABRecordID which is a typedef for int32_t.
ABRecordGetRecordID() is the API that you can use. However, apple documentation does states some noteworthy points about the ABRecordID returned by this API.
Every record in the Address Book database has a unique record identifier. This identifier always refers to the same record, unless that record is deleted or the data is reset. Record identifiers can be safely passed between threads. They are not guaranteed to remain the same across devices.
The suggested method as per apple guidelines is
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.
In my app, I am also checking for creation date of the contact since the name against the ABRecordID could have been changed by the user. Creation date of a contact DOES NOT change upon device reset.
Though I have pasted most of the content here, its always advised to read the documentation
Related
We have a table that contains a user's email address, their first name and last name and some date columns. The standard search works great for those.
I would like to provide a way of the user being searchable by their user id which is a GUID. The user id is not a visible piece of data. This search would really only be used by admins
I know I could use the data-search attribute on the user name column e.g.
data-search="43b30438-e3c8-4e27-8b31-5fcc52e53a3b me#test.com"
However that makes that row and any other row findable with just the number "43" as that GUID starts with 43 or "52" because it has a 5 followed by an 2. That is clearly not what I want. How do I make the users searchable by their GUID as well as their username but in the case of the GUID only when it is the whole GUID being searched for?
Thanks
Sql question.
I have a customer table with:
User id, name, email, phone
The customer can update their name, email and phone at anytime on an app.
How can I find out which user id had changes in name, email or phone number on a particular date?
Since your table doesn't store the date that they made the changes, you can't.
If you add a column with a datetime type (or whatever your specific database product provides) - you could call it LastModified or something like that - then the solution becomes trivial.
I'd give you a specific example, but because you didn't tell us what database engine you use, I can't guarantee to get the syntax right.
This is an issue with RDBMSes, you cannot as they generally store say a "photograph" of your data in time not a "film" of how it got there.
Based on the RDBMS you use, you can introduce an updated_at field which will hold when the last change happened to that row either from the "UPDATE" statement (say 'UPDATE phone=000, updated_at=now() WHERE user_id=999') or set it up to autoupdate see: create column for auto-date in postgresql
I have this table used when a user writes a note.
When writing a note, the user specifies if a sell-department and/or a buy-department should receive the note.
Each user can create a Case (lets say its just a table with case_id and case_text). And the notes the users write are related to a case.
So the table NOTES is (postgres database) something like this:
ID
TEXT (the message itself)
USER_ID (the user that writes the note)
CASE_ID (the case_id for which the note is been written)
Short word about users:
There are "ordinary" users and those working on a department. This should not make big difference for the description here.
When an ordinary user writes a note, let's say he want both buy-department and sell-department to be included (being informed about the note/see the note).
What happens now is that there is another table called UserNotes. It looks like this:
ID
IS_READ
NOTE_ID
USER_ID
DEPARTMENT_ID
READ_AT_DATE
So ordinary user with id = 1 writes this note and in the code (as he tells sell and buy-departments have to be included) I search for all the users working at that specific sell-department and all those working at that specific buy-department. I then put all these users in the table UserNotes. With IS_READ false by default.
When a user in the specific sell-department reads the note, I will then change IS_READ for this user's entry in UserNotes.
This is how it works today. I don't think this is scalable. I'm already getting performance issues. I don't think it is important to know when a note has been read. So because of this I was thinking that maybe the following solution could work. Please have a look and tell me if it could be better and the current one or if you have some other suggestion please let me know:
I drop UserNotes table. I add a new filed in table Notes: READ_BY. Here I will update the field each time a user reads the note.
I don't know if I could use some postgres-specific thing, maybe making this field a json-string and searchable.
I was reading a similar question on SO: How update an entity inside Aggregate, but I'm still not sure how a user interface should interact with entities inside an aggregate.
Let's say I have a User, with a bunch of Addresses. User is the aggregate root, while Address only exists within the aggregate.
On a web inteface, a user can edit his addresses. Basically, what happens is:
The user sees a list of addresses on its web interface
He clicks on an address, and gets redirected to this page: edit-address?user=1&address=2
On this page, he gets a form where he can modify this address.
I we decided to bypass the aggregate root, this would be straightforward:
We would directly load the Address with its Id
We would update it, then save it
Because we want to do it the DDD way, we have different solutions:
Either we ask the User to get this Address by Id:
address = user.getAddress(id);
address.setPostCode("12345");
address.setCity("New York");
em.persist(user);
The problem with this approach is, IMO, that the aggregate root still doesn't have much more control over what's done with the address. It just returns a reference to it, so that's not much different from bypassing the aggregate.
Or we tell the aggregate to update an existing address:
user.updateAddress(id, "12345", "New York");
em.persist(user);
Now the aggregate has control over what's done with this address, and can take any necessary action that goes with updating an address.
Or we treat the Address as a value object, and we don't update our Address, but rather delete it and recreate it:
user.removeAddress(id);
address = new Address();
address.setPostCode("12345");
address.setCity("New York");
user.addAddress(address);
em.persist(user);
This last solution looks elegant, but means that an Address cannot be an Entity. Then, what if it needs to be treated as an entity, for example because another business object within the aggregate has a reference to it?
I'm pretty sure I'm missing something here to correctly understand the aggregate concept and how it's used in real life examples, so please don't hesitate to give your comments!
No, you're not missing anything - in most cases the best option would be number 2 (although I'd call that method changeAddress instead of updateAdress - update seems so not-DDD) and that's regardless whether an address is an Entity or Value Object. With Ubiquitous Language you'd rather say that User changed his address, so that's exactly how you should model it - it's the changeAddress method that gets to decide whether update properties (if Address is an Entity) or assign completely new object (when it's VO).
The following sample code assumes the most common scenario - Address as VO:
public void ChangeAddress(AddressParams addressParams)
{
// here we might include some validation
address = new Address(addressParams);
// here we might include additional actions related with changing address
// for example marking user as required to confirm address before
// next billing
}
What is important in this sample, is that once Address is created, it is considered valid - there can be no invalid Address object in your aggregate. Bare in mind however, that whether you should follow this sample or not depends on your actual domain - there's no one path to follow. This one is the most common one though.
And yes, you should always perform operations on your entities by traversing through aggregate root - the reason for this was given in many answers on SO (for example in this Basic Aggregate Question).
Whether something is an entity or VO depends on the requirements and your domain. Most of the time address is just a Value Object, because there's no difference between two addresses with the same values and addresses tend to not change during their lifetime. But again, that's most of the time and depends on domain you're modeling.
Another example - for most of the domains a Money would be a Value Object - 10$ is 10$, it has no identity besides amount. However if you'd model a domain that deals with money on a level of bills, each bill would have its own identity (expressed with a unique number of some sort) thus it would be an Entity.
Each contact in the address book, has a unique Id,
1) will this Id ever change? if so when does it change? ie a user deletes a contact, will the other contact id change? how do we make sure of this? will not change now or in the future.
EDIT: would like to uniquely identify a contact, which id should I use as a reference?
The documentation says:
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.
Have one unique field like contact or address and compare the record's name with that field as well as id.