I am having no joy with the RavenDb profiler. There's output rendered in the browser, but the profiler always claims there are no requests and no sessions.
When the document store is created I make the following call:
RavenProfiler.InitializeFor(docStore);
And in my master layout I have this, just before the closing body tag:
#Raven.Client.MvcIntegration.RavenProfiler.CurrentRequestSessions()
As far as I can tell there's nothing more required in order for this to work (of course, I may be wrong) yet the output of the profiler is always as above.
I'm using version 3.0.0.0 of Raven.Client.MvcIntegration.
Any ideas?
I figured it out. It was an issue with how I resolved the DocumentStore via my Windsor Container. It turned out that I ended up with two instances of the DocumentStore, and the wrong one was registered with RavenProfiler. Once I ensured that only one DocumentStore was created, everything started working as expected.
Related
I am looking for some way how to save exact cookie in Cypress through whole test case.
Was using
Cypress.Cookies.defaults({ preserve: 'cookie_name' })
and
Cypress.Cookies.preserveOnce('cookie_name')
but this doesn't work anymore. And the new cy.session() is not working for me, because I use custom addresses per user and per new form.
Does anyone know of anything that works better than cy.session()?
The use pattern of cy.session() is a bit opaque, but since it replaces the older cookie config it probably can be made to work.
I have seen a note somewhere that session is likely to be revamped shortly.
Since Cypress.Cookies.preserveOnce('cookie_name') is deprecated but still available, maybe use that until session mark 2 comes along.
I'm stuck with this problem on Master Data Service (MDS).
I have an entity that has two domain based to other two entities.
I created the first business rule with the first domain based and it works perfectly.
But when I try to create a second business rule with the second domain based, an error appears:
200095 : Cannot specify more than one entity in MetadataGet
400003 : The attribute reference is not valid. The attribute was not found.
400003 : The attribute reference is not valid. The attribute was not found.
Obviously the attribute is valid. In fact, if I delete the first business rules, the second one is published correctly.
I think that MDS block a second business rules if you try to apply to a second domain based attribute.
This happened to us as well, and it seems that this error only occurs if a specific set of actions is taken:
We first restored the MDS 2012 database on SQL Server 2017
We upgraded a database using MDS management tool. Mind that the multi-entity business rules work fine now - they return no errors upon saving, can be published and successfully evalueted
We then realized that we are missing some code changes, so we decided to create a full model package using MDSModelDeploy.exe in our old MDS 2012
We deployed that package using MDSModelDeploy deployupdate command. After that the existing multi-entity rules are failing to publish, you are also unable to create new rules based on different entities within one entity. Unfortunately, we have found no fix for it, as there are simpler ways around it.
At this point we took a step back, restored and upgraded the old database once again, and it turned out that the rules worked, so it got to be the package that has broken those. I do not know what your situation was, since when we created a fresh model in SQL 2017 all of the multi-entity based rules worked perfectly, so I am curious to know what steps should be taken to reproduce the error in your case.
The only possible approach I can think of to fix the situation in point 4, would be to create an MDSModelDeploy update package from the corrupted model and another one from a new, healthy model, and then compare how the XMLs of the multi-entity business rules are structured. We did not try this one though, since we found the workaround described previously.
I am writing a provider hosted SharePoint 2013 application. I'm using SharePoint online.
Since the people picker isn't supported in this scenario, I need to build my own. I found the SearchPrincipals method. That seems like exactly what I'm looking for, but no matter what I try, the method is returning with 0 results.
What little information I've found around this method suggests that the problem is usually a permissions issue, but the user that I'm logged in as is a Site Collection Administrator (ClientContext.Web.CurrentUser.IsSiteAdmin is true), so that shouldn't be the case with me.
I've tried passing in virtually every combination of PrincipalType and PrincipalSource, even ones that didn't make sense. I've also tried passing in ClientContext.Web.SiteUsers for the scope, and also null, both of which I've seen used in my searches, and that didn't turn up any results either.
Any help would be appreciated!
I figured it out. The ClientContext of the CSOM (Client Side Object Model) allows the developer to make multiple --unrelated -- queries. It queues up these queries and does not execute them until ExecuteQuery is called. Even though SearchPrincipals is a static method off of the Utility class, it still translates the method call into a query and queues it up. The method will always return an empty collection, but once you call ExecuteQuery on the ClientContext, that collection is then filled with the results of the search.
Also, another problem that I ran into immediately afterwards was that I was getting an error that seemed completely unrelated to my query when I called ExecuteQuery. It turns out that there was code that previously executed that queued up some queries, but it never executed them, so when I called ExecuteQuery, it executed those queries as well, and one of those was erroring. If you are getting an unexpected error, it's a good idea to see if there are other queued queries that haven't been executed yet. You can check the boolean property HasPendingRequest to help determine this.
Hopefully this answer saves other people a lot of time!
Would it be ok to get a CF app to check for a valid database before proceeding to process that request?
This is because there may be instances where the database server may be down or being upgraded, hence an error comes when a db dependant request is made.
If there is no connection to the db server, the user can be safely redirected to a safe page.
Or can cfcatch work?
How can this check be done?
Thank you.
in your onRequestStart method of your Application.cfc file or in an Application.cfm file you can run a simple query to check that the database is available. Wrap the query in cftry/cfcatch. If the query fails, you can redirect the user in the cfcatch, if it succeeds, you can be reasonably sure that your database is "alive".
I've used such a check in one project. Code may looks as follows (not sure if it will work in versions of ColdFusion lower than 8), consider this sample as chunk of UDF written in CFScript:
// service factory object instance
factory = CreateObject("java","coldfusion.server.ServiceFactory");
// the datasource service
dsService = factory.DatasourceService;
// verify the dsn
return dsService.verifyDataSource(arguments.dsn);
Oh, I have even found small note in the code I wrote on my old laptop couple of years ago:
// [performance note] this server check takes 1-3ms at local PC (Kubuntu 7.10, CF8 + Apache2, Sempron 3500+, 1GB RAM)
While time looks like small I have found out that doing this check on each request is not really useful for my application. Any way I have a habit to use the try/catch extensively for errors handling. But if your datasources may cheange frequently it may have more sense.
Adding an extra query to every request to make sure that the database is up is a patently bad idea. A better approach would be to build a "maintenance mode" switch into your application, that you would manually enable when you are doing planned maintenance (upgrades, etc).
If you want to have a "friendly" page displayed when an error (like database issues) occur, then use the onError() method in Application.cfc and/or the <cferror .../> tag in Application.cfm, as a global error handler.
If you are worried the db could vanish, I would implement a "SELECT 1 AS A" query in your OnRequestStart handler that runs only every N minutes. This can be accomplished by using the query caching feature. I'd start with performing the query every 30 min.
I have gone through the (painful) process of writing a custom template tag for use in Django. It is registered as an inclusion_tag so that it renders a template. However, this tag breaks as soon as I try to change something.
I've tried changing the number of parameters and correspondingly changing the parameters when it's called. It's clear the new tag code isn't being loaded, because an error is thrown stating that there is a mismatch in the number of parameters, and it's evident that it's attempting to call the old function.
The same problem occurs if I try to change the name of the template being rendered and correspondingly change the name of the template on disk. It continues to try to call the old template. I've tried clearing old .pyc files with no luck.
Overall, the system is acting as though it's caching the template tags, likely due to the register command. I have dug through endless threads trying to find out if this is so, but all could find it James Bennett stating here that register doesn't do anything. Please help!
I have gone through the (painful) process of writing a custom template tag for use in Django
I agree that the process for writing the template tag in django is more elaborate than it needs to be.
But let me point you towards some of the third party apps, that when installed, a template tag is just another python function (or class).
http://github.com/alex/django-templatetag-sugar
http://github.com/codysoyland/django-template-repl
Firstly, I can't imagine what's complicated about inclusion tags. Writing a completely custom tag from scratch, yes: that's complicated. But inclusion tags are simply three lines of code and a template - what's complicated about that?
Secondly, all Python code in your Django project is loaded once by the server [*], and remains until it is restarted. The dev server usually detects changes and restarts itself to reload the code, but this doesn't always work. You should get into the habit of checking the console to see that it does restart, and doing it manually if necessary. Note that this has nothing whatsoever to do with caching.
[*] strictly speaking, once per process, but the dev server is single-process anyway.
In case anybody else encounters this: the exact caching mechanism is unclear, but restarting the django dev server fixes the problem.