I have been writing an Square Connect integration that rests on the fact that an item has one and only one ID, even when it is present in multiple locations. After testing with a subset of products on a separate Square account/App, things were working smoothly. I have now pointed the integration at the "real" Square account/App, using that account's credentials, which contains the same subset of products in addition to many others, and the integration is failing. It seems I have many items that now have a unique ID for each location. This means that a single item has multiple IDs. The item only displays once in the Square dashboard, but there are two unique IDs associated with it. In fact, I have one item that has two IDs, yet those IDs share a single variation ID.
I have also noticed two different formats of IDs, which from my research sounds like a variation due to information created pre- and post- a certain date.
Format 1: XXxXxXXX-xxXX-XxXx-XXX-XXXxxxxxxxXX
Format 2: XXXXXXXXXXXXXXXXXXXXXXXX
I suppose the first question is, is this normal behavior? And if not, any thoughts on what might be causing it and is there a way out of it?
There are some nuances to items with older accounts. Items were originally scoped to a location, which doesn't quite make sense with larger multi-location businesses. Internally we are migrating to a location independent item catalog, which should be invisible to you as an end user (save for the change in formats, like you mentioned) and depending on the date of your account it might have a mix of "old" and "new" item ids. It seems like you have basically a "new" location and an older one.
Basically in our current model you are only guaranteed that items will have unique ids within a location. We are working on new APIs that will allow you to manipulate items across locations more easily.
Related
I'm trying to write microservices in Java. I've implemented GraphQL endpoints using graphql-spring-boot-starter.
Now I have a problem how to make it efficient.
Datamodel is like a tree and I need to query for data from multiple services at once. The problem is how to filter for a member of collection, something like CONTAINS in database, but data is not in separate table, but separate microservice. Maybe the problem is that domain is not correctly splitted between services?
Let's make an example: I have 3 microservices: users, libriaries, books. Every library have collection of users and books (just list of identifiers, like foreign keys). Every book has a name and genre. Every library have lists of books borrowed by user (identifiers too).
Question 1 - should library hosts list of books and users (just identifiers, like foreign keys)? Is it correct approach?
Question 2 - I want to find libraries in which specified users (by surname) have borrowed books of specified genre. Going from top I need to first find libraries containing users. Not easy, as we have names in different service. We need to query first for users, gathers their identifiers, and now we are able to query for libraries. But it isn't all. Now we need to find books for every user and check genres - in different service. And it's not all. I want to have everything presented in nice way, so whole output should be sorted and paged. It force me to collect all data from all services, then page and sort it, which of course will not be efficient.
Please don't concentrate on this example, I'm looking how to solve general approach, not this one example. I've tried to use Datafetchers but it's troublesome and there are not good examples of calling Graphql-to-GraphQL. Most examples covers calling REST endpoints etc.
I'm working on a syncing process between offline-first databases and a central server. As a simple example, there are items and departments and an item belongs to a department. Each client can modify any of the entities.
I know for text documents there are algorithms/technology for handling conflicts like OT and CRDT:
https://en.wikipedia.org/wiki/Operational_transformation
https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
Differences between OT and CRDT
But I'm wondering if you can either use these for more complex structures like you might have in a database. In my case, let's keep it simple and say you have :
items - id, name, department_id
departments - id, name
Changes in properties like "name" in individual elements are manageable (maybe using a version, delta, timestamp). Deletes are a little tricker, but you might just discard the name change because the element is deleted.
And it's even more tricky when there are relations. What happens when one client moves items to a department and the other deletes the department.
At a certain level, some of these conflicts are similar to those that could happen in text using OT. Someone changes a title and someone else deletes it. Or someone adds an element to a bulleted list and someone else moves the list to a different part of the document.
My question is, can you use OT or CRDT for relational data and if so, how would you do it? If not, are there other similar algorithms or techniques to handle conflicts in relational data?
I was messing around with the Square Connect API, and after uploading some items and finding out they had incorrect pricing (I was sending the amount in dollars, not cents) I decided to delete all of the items and start over. I am passing in item ids so that I can cross reference the items with our in-house database. Unfortunately, it appears that after I've deleted an item, I can't recreate it with the same old id. How can I fix this?
Unfortunately, item and variation IDs can never be reused for a given merchant. I will update the documentation to better clarify this limitation.
As a couple of potential solutions for your issue:
You could recreate your item library with item IDs that all have the same prefix, followed by the corresponding ID in your in-house database. Then prepend or remove the prefix when translating between IDs in your two systems. Of course, this solution is still susceptible to the same root issue, so you'd have to make sure not to delete any items.
Store the ID mapping in the user_data field of your item variations. You can set the user_data field with the Update Variation endpoint.
i have a view in an xpage with some entries (lets say clients). I have an acl group of persons (clients) that contains some of the clients of the view. Now i want to use the search attribute of the view to show only entries that belong to the group.
I already use search attribute to select users by name e.g:
FIELD Name Contains "Chuck Norris"
Is there any similar query? (maybe using #isMember on the field....?)
UPDATE: i will have the group entries (client names) into a text list in a document too. so can i filter the "name" field of the view based on the values of a text list?
Perhaps using a reader field is a good idea. You're talking about restricting document access to a group of Domino users - that's exactly what reader fields are for.
For example, make your text list field containing client names into a reader field like this:
var item = document1.getFirstItem("myfield");
item.setReaders(true);
document1.save();
myfield needs to contain canonical names (CN=firstname lastname/O=organisation).
Using reader fields, you don't need to do any view filtering at all, it happens automatically. If you have really many documents (say, half a million or so), it could slow down things, otherwise, it's a nice approach.
When you want to restrict displaying documents only in one certain view reader fields are no solution, though. In that case, you need to do the view filtering yourself as you tried.
If you want to filter only for ONE certain client, then using a categorized view is the way to go. You can give the view panel the name of one client as category filter then.
If you want to filter for multiple clients, you need to do it based on fulltext search, just as you already tried. In that case, make sure you're working with Domino 9. Previous Domino versions don't apply the view sorting order to a fulltext search result, which means you have to search it manually using custom javascript or so, which is complicated.
Or, as Frantisek suggested, write a scheduled agent which puts documents in folders depending on their clients - but depending on the number of clients you want to filter the view for this may lead to many folders, which may lead to other problems. Furthermore, you need to make sure to remove folders when they are not needed anymore, and you have a lag until new documents appear in a folder.
So in a nutshell, if you want to do an application wide restriction based on client names, use reader fields.
If you want to restrict for one client name at a time, use categories.
Otherwise, use fulltext search with Domino 9.
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.