I recently implemented an autocomplete/autosuggest feature driven by solr. My solr implementation is using the rails sunspot gems. The autocomplete search does not go through rails at all, but goes through an apache reverse-proxy to the solr server directly. So, in this case, the role of sunspot is to re-index when a record is created or updated (or deleted).
My problem is that when a record is created or saved, triggering a delayed_job reindex, it is not reflected in the autocomplete search in production only. When a record is saved in development or staging, the changes are immediately reflected in the autocomplete search.
My code and my solr configs are all managed in git, so they are identical in all my environments (development, staging, and production). I have not done any production specific configuration changes (yet!). I have copied the MySQL database and solr index files from production back to the other environments as well, to make everything the same. I've restarted but rails and solr many times to be sure to be sure.
In production, I see the jobs go through delayed_job, and I see the update in the sunspot solr logs. Although, most of the log output is still greek to me. I've done a line-by-line comparison between production and development and they look more or less the same.
I've tested directly against the solr server using curl to make sure it's just me and solr - no apache, no networks, no browsers.
When that same record is saved, it initiates jobs to reindex a bunch of its child objects, and those do get reindexed as expected.
Also, if I reindex using the rake task for that model, it rebuilds the index correctly. That only takes a few minutes, so that is what I'm reduced to doing now.
So, the problem is this one Type, in this one environment, on create/update only.
The only difference I can identify is the load, although my site has so few users it's hard to think it matters.
Any idea what could be causing this, or what I should look at next to figure it out? My guess would be caching, but since I have not done any kind of production tuning, it should be the same. Unless sunspot does something that I'm not aware of.
Related
I have been asked by a client to assist in making the web frontends of number of Lotus / IBM Notes databases, used for critical LOB functions, compatible with modern browsers.
As it stands, the web frontends of these databases only work in IE7, and even then they're temperamental at best. The JS uses IE-specific extensions, everything is in tables, and they render poorly on pretty much every browser available today. With IE7 no longer in support, they want to modernise these interfaces.
I have very little experience with Notes, but as an exploratory exercise I've managed to open up the databases in Domino Designer, add a few Stylesheet / Script resources, include them in the $$HTMLHead variable and reworked one Form to use a frontend framework, which looks good.
Obviously working on live applications is out of the question, so my thinking is to take a copy of the NSF files, and make the changes on the copies. My question is: how can I then deploy only the form / subform / resource changes to the 'live' NSF files?
Deployment:
In your new modified database :
You define in the Database properties that is a Database file is a master template (give a name)
In the production database :
first do a backup ! copy (only design) to a new copy of the prod
You define in the Database properties that it inherits from master template (same name)
on the prod make refresh design
more details : https://www.ibm.com/support/knowledgecenter/SSVRGU_9.0.1/com.ibm.designer.domino.main.doc/H_ABOUT_REFRESHING_A_DESIGN.html
Sorry to state the obvious, but since you have a Notes client and a Domino server, you have a quite extensive documentation at your disposal in the form of databases located in the /help/ directory. Make sure they are full-text-indexed.
And since we are on the subject of templates, Domino comes with a host of ready-made, ready-to-use apps that you can customize and canibalize. Look for discussion9.ntf for starters.
You may want to start here, then go there, and finally that will give you the keys to build word-class web apps on Domino.
Last thing, if you are on V9, the Designer help is crap. Grap a copy of the 8.5 version. Seriously.
If you want to build a modern web based front-end to existing Domino data, take a look at the following presentations:
http://www.slideshare.net/TexasSwede/ad102-break-out-of-the-box
and
http://www.slideshare.net/TexasSwede/break-out-of-the-box-part-2
As others already said, you should create a template and then just refresh/replace the design of the production database using that template.
You may want to consider working with an experienced Notes/Domino developer for that project, there are quite a few caveats and workarounds you need to know know about...
Need a push in the right direction with this one.
I want to "dev0ps" the workflow of our local development with docker.
As best practice our mongodb should run in a seperate container, having a volume attached and working. (this part checks out fine)
Our developers should then keep the data in sync, so its able to be "pushed & pulled".
Can i achieve this with git? (The data folder is around 500mb, but this is just a fresh project)
Should i write a script that performs a mongodump and upload it (to git?)?
Should i consider spinning up a mongodb server of my own, where they push and pull from?
thanks in advance!
I see what you're trying to achieve, but I don't think the best approach is to keep neither the data from one local working copy in sync inside Git, as this is likely to provide inconsistencies in the Database if Developers have different copies of the data.
The best thing you could do is have a set of Fixtures (Application Data inside the MongoDB database) which is inserted and deleted via your code, that way you control what goes inside the database and what does not, That data can very well be included in the Git repository in a folder called fixtures or database.
You could also have different sets of data, one for developing, one for testing, etc. As you can see you can make it as complex or complementary as possible.
I've been using this approach for more than one year and has not presented any problems.
Let me know if you have any concerns about this approach.
We have recently begun using Entity Framework for accessing all the various databases we touch on a regular basis. We've established a collection of library projects, one for each of these. For many of them, we're accessing established databases that do not change, and using DB first works just great.
For some projects, though, we're developing evolving databases that are having new fields and tables added periodically. Because these libraries are used by multiple projects (at the moment, just two, but eventually many more), running a migration on the production database necessitates a republish of both/all sites that use that particular DB's library. Failure to update the library on any other site of course produces the error that the model backing the context has changed.
How can we effectively manage the deployment/update of the Code-First libraries to all of the sites that use them each time a change to the database is made?
A year later, here's what we came up with and have been using.
We now include the following line in the Application_Start() method:
Database.SetInitializer<EFLib.MyHousing.MyHousingMVCContext>(null);
This causes it not to throw a fit if the current database model doesn't exactly match what's in the code. While there is still potential for problems if non-backward-compatible changes are made, this allows for new functionality to be added without the need to re-deploy every site that uses these libraries when the affecting changes are not relevant to that particular site.
I am trying to come up with an optimal workflow for updating my web application running on play framework.
I use the start script to launch it but what is the best practice for updating the code so that it is as seamless as possible for the users?
In an Apache + PHP application often it is sufficient to drop new *.php files in the directory and in many cases the change is not even noticeable for the user.
Could you share your workflow for doing that with play framework?
The play framework is very different from using something like php on apache. Php is interpreted by Apache when a page is requested by a user. So all you need to do is change the file to update the site. With java however (unless you are using .jsp files and even sometimes then) the code is bytwise compiled and the webserver needs to load it and its libraries at start up. What this means is that just replacing newly compiled files will not work. You need to restart the web container or get it to reload the application to pick up the changes. This is always going to be noticeable to any users that try access the site at the same time as the reload is being completed.
You could have a web server (doesn't have to be Apache) that points to your current play installation as a proxy and bring up a new version of it in parallel and then switch your proxy webserver point to your new version and turn the old version off. This is probably the easiest way to do this and could be scripted.
Another way is to just have a web app that redirects the the user to the app and doing a parallel change similar to the one above.
Both of these options require some setup and coding to get them to work seamlessly. However the work is probably worth it as once you have it setup rollouts to production become very easy.
There are some queries for which we need resolution before we purchase sitefinity 5.0 license. I would really appreciate if could get answers to these
What are the recommended guidelines to setup the sitefinity project in the source control? If there 4 to 5 developers working on the project, what should be the starting point in setting up the initial codebase? Do every developer has to create the sitefinity website and DB on their dev-boxes?
Is it recommend to setup a common DB for the sitefinity website where all the dev-machine would be connecting to do the development, if not what is the alternative approach?
Is there any online documentation available related to build and release of sitefinity web applications, other than publishing from within the visual studio?
Thanks
Gaurav
We've been developing with Sitefinity since version 2, with multiple developers.
To answer your questions specifically:
Have a single developer (ideally your lead dev) create a clean sitefinity visual studio solution on their local machine. Check it into your source control repository and have each additional developer pull down a copy from there. You're now all in sync.
In terms of database location, two approaches work - either have each person run a local database, and in the web.config setup the connection string location as . (i.e. local). That way no one needs to check out the web.config to run it. Otherwise use a common development/testing server for the database. We've found the easiest way is to each have a local DB, unless multiple devs are working on very specific tasks together at the same time.
I have not seen any online documentation related to building outside of visual studio. If you have TFS or a MS build server, it should work fine as well.
In general, there is nothing 'special' about Sitefinity's architecture that separates it from any other .NET / MSSQL solution. Best practice that falls under these technologies still applies.
My experience with source control has been one of two options. If you are using SQLExpress user instance databases (that is an mdf in the App_Data folder) I've found versioning everything except this database file and the dataconfig.config file in the configurations folder will allow every developer to run their own copy of the website.
from there you can either do some kind of manual merge of the database or just create a new one for deployment.
This option works best if your developers are simply working on features, and don't need to be working on an actual website, modifying content that has to keep in sync.
Alternatively, if they do need to work with live content and it all has to be the same, create the database in a shared server they all have access to, and version everything (since the connection string should be the same for both).
This works best if your developers are doing work to support existing content as opposed to say creating modules that manipulate the database (creating tables, columns, etc), because keep in mind with this method, everyone will be accessing and modifying the same database.
Personally, my preference is option 1, because it allows each developer full control over their environment. the source could then be merged and shadowed to a staging server, so that the main site content is only affected by this one instance.
I hope this is helpful!