On the intents there's a limitation of 20 parameters.
Why does this limit exists? Is there any way to use more than 20 entities in an intent?
Thanks!
Best whishes.
The limit exists for processing speed and efficiency.
Depending on your exact needs, you may be able to create a composite entity.
Related
I have to design a schema in such a way that I can store user id and their order which can be multiple products like bread, butter plus in addition to that I want to store the quantity of product ordered, please guide.
It is difficult to provide you with a real solution to your problem as designing a NoSQL DB structure depends on how you want to access your data. You can keep orders as nested/embedded documents in the User model or store them in a separate collection. In the first case, you will have all the data in one requests, but you will not be able to query and receive orders, that match certain criteria as you will get all orders including those that match. And then you would need to filter them out. Or you could use aggregation to get exactly what you need.
However, there is a limitation to keep in mind. MongoDB document has a size limitation - 16 megabytes. Since users may have very many orders, you can reach the document size limit for some users for sure. Aggregation also has a limitation - Pipeline stages have a limit of 100 megabytes of RAMe but you can override it.
Having orders in a separate collection would require you to separately load them for users. While it is one more request, it will give you more flexibility in terms of how you query them.
Then, of course, create/update operations are also done differently for both cases.
My advice would be that you carefully design your application first - what data you need and where you will show it, how you create/update it. It will give you a better idea and chances are that relational DB will be a better choice for what you need (though absolutely not necessary).
I want to search change log under "cn=changelog". I can search the result normally if the result entries were not a lot. But if there are a lot of entries in the result, the memory will be not enough. So, I want to page the result. How can I define the size limit?
I also refered to https://bugster.forgerock.org/jira/si/jira.issueviews:issue-html/OPENDJ-1218/OPENDJ-1218.html. While, I wonder how to define a filter to support "changeNumber". And in my result, there is not this attribut "changeNumber". Why?
Please help me how shoud I do?
BTW, I am using OpenDJ 3.0.
Size limit is an option of the client call. You can always specify the maximum amount of entries you want to be returned (the server has it's own limit and will enforce the smallest between the 2).
How to define the size limit depends on what you are using as client, and you did not mention it.
Can you provide details on what you are using to search (tool, library...) and what is the filter and options you are currently using ? It's difficult to provide help and suggestions to improvement when there is no detail.
I have a main application that allows a user to edit all of their data (about 20 fields). When this is updated I add this to a Service Bus topic which I have other areas of the system subscribing to.
One of these subscriptions only cares if a single field is updated (phone number). I'm wondering what is the best way to handle this?
Looking at the GitHub example here, it states:
The cost of choosing complex filter rules is lower overall message throughput at the subscription, topic, and namespace level, since evaluating rules costs compute time. Whenever possible, applications should choose correlation filters over SQL-like filters since they are much more efficient in processing and therefore have less impact on throughput.
So from what I can gather I could add what properties have been updated using the properties property on the BrokeredMessage class and filter based on that but that is not recommended based on the above statement.
I could let the message go through and action it (this would just update a row in a table to the same value) but this seems redundant.
Do I have any other options?
If you have predefined values you'd be filtering on for that subscription, use CorrelationFiter. In case it requires conditional match (e.g. a phone number that starts with area code 321), then SqlFilter is absolutely fine. It really depends how much of filtering you're going to perform. My suggestion would be benchmarking and measuring the performance, tweaking your filters to give you the optional result.
I am trying to save data in memory that I would be able to retrieve quickly in my filter part. Indeed, when i receive new documents i want to retrieve former documents related in order to compute some new metrics.
Can anyone tell me if it is possible and if yes how could I achieve that ?
Thank you very much.
Joe
The closest thing to achieve this would be to use the elasticsearch filter in order to query an ES cluster for some document or the unofficial memcached filter, which is probably more up to that task given the features of memcached.
I'm not aware of any official/unofficial redis or hazelcast filters, though, but that would also be an option since they are both caching technologies.
You should also have a look at the existing metrics filter which might also be of some help depending on your use case, which, by the way, you should detail a bit more if you desire more precise help.
I am developing an Azure based website and I want to provide search capabilities using Lucene. (structured json objects would be indexed and stored in Lucene and other content such as Word documents, etc. would be indexed in lucene but stored in blob storage) I want the search to be secure, such that one user would never see a document belonging to another user. I want to allow ad-hoc searches as typed by the user. Lastly, I want to query programmatically to return predefined sets of data, such as "all notes for user X". I think I understand how to add properties to each document to achieve these 3 objectives. (I am listing them here so if anyone is kind enough to answer, they will have better idea of what I am trying to do)
My questions revolve around performance and security.
Can I improve document security by having a separate index for each user, or is including the user's ID as a parameter in each search sufficient?
Can I improve indexing speed and total throughput of the system by having a separate index for each user? My thinking is that having separate indexes would allow me to scale the system by having multiple index writers (perhaps even on different server instances) working at the same time, each on their own index.
Any insight would be greatly appreciated.
Regards,
Nate
Of course, one index.
You can do even better than what you suggested by using ManifoldCF (Apache product that knows how to handle Solr) to manage security.
And one off topic, uninformed suggestion: I'd rather use CloudBees or Heroku (or Amazon) instead of Azure.
Until you will use several machines for indexing I guess it's more convenient to use single index. Lucene community done a lot of work to make indexing process as efficient as it can. So unless you intentionally want to implement distributed indexing I doesn't recommend you to split indexes.
However there are several reasons why you would want to split indexes:
if your machine have several IO devices which could be utilized in parallel. In this case, if you are IO bound, splitting indexes is good idea.
splitting document fields between indexes (this is what ParallelReader is supposed for). This is more exotic form of splitting, but it may be a good idea if search is performed using different groups of fields. Suppose, we have two search query types: the first is using field name and type, and the second is using fields price and discount. If those fields are updated at different rate (I guess, name updates are far more rarely than price updates), updating only part of index would require less IO resources. This will give more overall throughput to the system.