Thanks

You're really trying to get those Global Masters points, aren't you?

Based on the docs you linked, I found /csp/healthshare/<namespace>/EnsPortal.Deployment.DeployProductionChanges.zen

This allowed me to select a "Deployment" and successfully accomplish my goal.

This is terribly unintuitive.  Not only is the context completely different, but there is no parity among terminology.  To improve this, there are two options:

1. Change the "Export" process.  First, it should not be called "Export", it should be called "Create a Deployment" or "Create Deployment Package".  Second, it should not be in the actions for the adapter/operation, it should be in the main Ensemble menu.

2. Change the "Import" process. First, it should be called "Import" and not "Deployment".  Second, it should be in the context of the production, located in a similar place to the Export button.  Ideally, you would click "Production Settings" and there would be an "Import" button there.

I could probably be convinced either way, however at some point you have to wonder, if a post has so many disparate threads/conversations, is the topic too vague?  Perhaps a new post is warranted.

I think of both extremes.  Reddit is 100% threaded and gets very out of hand, but StackOverflow is only minimally threaded (each answer has comments).  I think it works well there, but I suppose these forums fall somewhere in between.  It's not a simple question/answer site, but a place for discussions as well.  I grew up on dial up BBSs and later phpBB though, and non-threaded conversations were just a way of life that I never noticed a problem with.

As Evgeny said, perhaps we just wait for it to be a problem, then try to come up with a creative solution.

edit: for what it's worth, many modern forums have the option of "Flat, Threaded or Hybrid" views.  Also, here's an interesting take on the subject.

These namespaces span multiple servers, so I think that rules this out?  Also, each of the copies will have minor changes (each FTP out adapter will have a different filename prefix, etc).  Plus, it sounds super complex for this simple use-case.

edit: But I appreciate the quick response, and mapping sounds really cool otherwise!

I may have realized what I was missing. These "documents" are generated on the fly so I guess you wouldn't be able to reference a static table of document contents.  I was led to this by running the following query on the first 15k rows or so.

SELECT DocumentId, HomeCommunityId, RepositoryId, count(AggregationId)
FROM HS_IHE_ATNA_Repository.Document
GROUP BY DocumentId, HomeCommunityId, RepositoryId

These are the numbers of duplicates

ie, only 2 documents were duplicated 8 times.  The vast majority only had a single entry. Still, if we extrapolate this out, that's a lot of duplicated data in my opinion.  If my math is correct, in this sample, 21% of the documents records are exact duplicates.

I'm not really talking about speed or performance.  It just seems strange to me to have a table that stores "document base data" in an event based format.  I'm not sure if I'm being clear, so let me see if I can provide a visual

Here is a representation of the way I understand it to work:

And here is what I would expect to see:

Am I missing something?

We can add HIE tag, would you please point the related articles and questions?

This would be great, thanks.  I can start a topic eventually with links to posts that should be tagged, but probably not today.  Although, it would be really nice if community members could tag posts freely.

I'm actually a spambot designed to get responses. Someone just pointed me at the wrong domain. 

But that's not inefficient?

So can you answer the question: Does this mean that if the same document was requested 1,000 times that there will be 1,000 entries for it in the .Document table? 

Now let's pretend this is a real post, with real content and real words.  It's so long that it's unrealistic, but it's long enough to be useful.

get?

will

it

small

how

just

wonder

I

see.