I'm trying to build a very simple location-based app and I have all of these services at my disposal (Foursquare API, SimpleGeo, Google Places, etc). All seem to provide me a list of venues (bars, coffee shops, stores, etc) near a given longitude latitude. This is great but once the users see the venues, they will be able to write reviews about each venue (for example). Now, what do I do with this data?
User ID (users for my app)
Venue Name (retrieved from Foursquare API)
Longitude, Latitude
Foursquare Venue ID
Review
Do I store this in my database? What happens if the venue name changes on the Foursquare servers? If I don't store this in my database, I'd have to do a lookup to retrieve the venue name and details every single time I want to return a list of reviews in the area. Can someone offer some advice on how to conceptually design a venue-based location app. Thanks.
Store the essential 3rd party info in your database but treat it as a cache. Have a background task that checks for updates every few minutes, days, or weeks depending on the likelyhood & severity of changes. In between updates the user may get stale data but hey, that's life... at least they got it fast. In doing your updates, don't update everything at once or you'll run quickly into API throttling limits.
Related
Building custom integration for a client with their e-commerce store and Zoho. They essentially have a referral program, for the easiest explanation. When someone purchases, we need to keep track of who the referring person was in Zoho and credit them - I have this all available. They only sell 1 product so we don't need actual financial / sales data, just the number of units attributed to the person in Zoho. They eventually want to be able to have reports generated in Zoho to tell them how many units each person is doing per month, who is their best performer, etc.
All the potential referral people are stored as Contacts in Zoho. My task is simply getting the data from the e-commerce site into Zoho, I do not have to create any reports or anything within Zoho. I have no experience with the Zoho world so I am not quite sure where the best place to even put this data as there are so many different Zoho "things" to use. I thought about using Invoices, but again we don't necessarily need the transaction data just counts and when they happened to produce the above stated reports.
I was finally able to reach someone at Zoho: Sales Orders are the right place to put this.
I'm trying to create a recurring payment on Square, ala Stripe subscriptions. However, I am having trouble retrieving a customer's card information (specifically customer_card_id) to pass into Charge.
Our flow is such:
A customer visits to our store and subscribes to a membership, which we process via the point of sale app.
We continuously poll Square to retrieve payment information, and create membership records appropriately.
When the user's membership period expires, charge them for the next month's membership.
When researching RetrieveCustomer, I find that there is a cards property under Customer, but iterating through all the Customers under our account, they all have cards = None despite us having taken card payments via the point of sale app.
Also, looking at ListTransactions, there doesn't seem to be anything that might be customer_card_id. The IDs I see there are tender ID, location ID, and transaction ID. The card_fingerprint also looks promising but that doesn't seem right either, since a card can have both an ID and a fingerprint.
Am I missing something? Where might I find customer_card_id?
EDIT
Looks like I was dumb and my local instance of our application was just out of date with transactions from Square. After updating my data with customers we've processed since the last time I updated, customers with a non-None card property now show up. tristansokol's answer below is still valid however.
How do you process the first charge? You need to explicitly add the card on file, it won't be added by default from processing a transaction from a customer. See: https://squareup.com/help/us/en/article/5770-use-card-on-file-with-the-square-point-of-sale-app
I'm looking to store Google Place ID for several different places (millions of records). I have purchased a premium plan usage.
Will Google deduct my credits for those records which don't have a Place ID (or Place ID is not returned) ?
Maps API Credits are deducted based on the number of requests made to the Places API, not the values or fields like Place ID, returned within those requests. Credits will be consumed anytime the request doesn't return an error so if you're getting some results (or ZERO_RESULTS), credits are being consumed.
As a Google Maps API Premium Plan customer, feel free to contact the support team for these sort of questions.
I have an application where users of the application can have many contacts ( other users of the application ) related to them. I would like to maintain a relation between a single user and its set of contacts. At any given point of time, I do NOT need to know anything more than the direct set of contacts for a particular user, i.e, contacts of contact of a particular user is not of relevance in this application.
Any suggestion on how to organise this data within the database? Please note that the number of users could go up really high.
Just to add some extra info, the database I am using right now is Mongodb and language being used is Ruby.
The only model right now before thinking of building all these relations is the Users model which stores details of each user registered onto the application. Now as I mentioned above, I need to built the specified relation between the user and its set of contacts. Any help would be highly appreciated.
I have a web application that syncs Outlook contacts to a database (and back) via CDO. The DB contains every contact only once (at least theoretically, of course doublets happen), providing a single point of change for a contact, regardless of how many users have that particular contact in Outlook (like Interaction or similar products).
The sync process is not automatic, but user-initialized. An arbitrary timespan can pass before users decide to sync their contacts. A subset of these contacts may have been updated by other users in the meantime.
Generally, this runs fine, but I have never been able to solve this fundamental problem:
How do I doubtlessly identify a contact object in a mailbox?
I can't rely on PR_ENTRYID, this
property changes on contact move or
mailbox move.
I can't rely on my own IDs (e.g. DB
table ID), because these get copied
with the contact.
I absolutely can't rely on fields
like name or e-mail address, they
are subject to changes and updates.
Currently I use a combination of 1 (preferred) and 2 (fall-back). But inevitably, sometimes users run into the problem of synching to the wrong contact because there is none with a given PR_ENTRYID, but two with the same DB ID, of which the wrong one is chosen.
There are a bunch of Outlook-synching products out there, so I guess the problem must be solvable.
I had a similar problem to overcome with an internal outlook plugin that does contact syncing. I ended up sticking a database id in the Outlook object and referring to that when doing syncs.
The difference here is that our system has a bunch of duplicates that get resolved later by the users. When they get merged I'll remove the old records and update outlook with all of the new information along with a new id.
You could do fuzzy matching to identify duplicates, but duplicate resolution is a funny problem that's mostly trial and error. We've been successful at implementing "fuzzy" matching logic using the levenshtein distance algorithm for names and addresses cleaned down to a hash code.
Good luck, my syncing experiences have been somewhat painful.