After restoring a semantic media wiki installation from backup the SMW engine does no longer return any query results. I have (re)inserted all regular pages, all form pages, all property pages into the new MW instance. So all content is there but query results remain empty. It seems as the internal data structures maintained by SMW are not filled. How can this be fixed? Are there any specific scripts that need to be run manually?
Indeed the internal SMW cache is not filled after restore. The solution is simple: You need to go to extensions/SemanticMediaWiki/maintenance and run the script rebuildData.php which will reparse every single Wiki page and fill the SMW database accordingly.
Be aware that for this to work your Wiki needs to be configured properly. By default SMW will not process additional namespaces! You need to enable this manually for every single namespace you add yourself in LocalSettings.php after the line where you enable SMW in this file. (This configuration will only have effect if you do this after the line that enables SMW.)
Related
I am going through documentations for project configuration in craftcms not sure what is the different between project-config/write and project-config/modify?
project-config/write takes the config currently stored in the database and writes it out as YAML files in the config/ folder. You usually don't need this since Craft does this automatically whenever you change something in the backend (unless you have turned that off).
project-config/rebuild attempts to rebuild the entire project-config based on the state of the entire database. This is only required in rare edge cases.
Rest you can check the official documentation here:
https://craftcms.com/docs/4.x/project-config.html#what-s-stored-in-project-config
My aim is to temporarily turn off some of the Text Sinks for a specific batch run. My motive is that I want to save processing time and disk space. My wider aim is to easily switch not only between different text sinks but also parameter files, data loaders, etc.
A few things I've tried:
manually put the xml-files linked to the text sinks in a different folder --> this creates an error message (that possibly can be ignored?) and does not serve my wider aim of having different charts/data loaders/displays/etc.
create a completely new scenario-tree by copying the .rs folder and creating a new Run Configuration for that .rs folder --> if I want to change the parameters in all the scenarios at once, then I need to do it manually
try to create a new scenario.xml file (i.e., scenario2.xml) in the hope this would turn up as an alternative in the scenario tree --> nothing turned up in the GUI
Thus: Is there another easy way to temporarily turn off parts of the scenario?
What we've done in the past is create different scenarios for each type of run (your second option). Regarding the parameters in the scenario folders, you could potentially run a script to copy the version you want to all the scenario folders so you don't have to manually adjust each one.
I have 2 instances of Odoo v9 running in the same server (Ubuntu 14.04). I want to make changes (install modules, change source code or anything) in the developement instance and after confirming they are OK, move the changes to the Production Instance. Is there anyway of doing that without repeating the whole process of development?
Thank you.
As I can understand you do not want to stop the production instance.
If they are only XML files you might be able to get away by only updating the module from the frontend (Apps-> Your Module -> Update. Although if you have modified the __openerp__.py file inside your module you have to enter the debug mode and click Update Apps List first of all.
For changes in files that are inside the static folder of your module, you do not need to stop the server. Although, your users must click ctr + shift + R in order to flush their caches and bring to their browsers the new content.
For Python source code I am afraid that you have to stop both instances of the server so that the code can be correctly recompiled.
(See note 1 on this)
In the end you should stop and update everything because unexpected things might pop up at random times due to resources not been properly updated.
Note 1: The Python documentation about the compilation of Python modules above others mentions:
As an important speed-up of the start-up time for short programs that
use a lot of standard modules, if a file called spam.pyc exists in the
directory where spam.py is found, this is assumed to contain an
already-“byte-compiled” version of the module spam. The modification
time of the version of spam.py used to create spam.pyc is recorded in
spam.pyc, and the .pyc file is ignored if these don’t match.
So theoretically if you modify fileA.py in a module and a new fileA.pyc is generated the server will be able to interpret and use it. In any case I had an issue with two instances running where the py file was creating the field and the XML file was using it and the server reported that a filed had not been created for the XML view, that means that the server did pick up and parse the XML file but did not recompile the py.
My task: to move the directory containing the databases and filesystems for a Ravendb-installation from one drive to another (because of disk-space issues) without moving or altering the Ravendb-installation itself.
I managed to move the databases by:
shutting down the Ravendb service
Moving the data-folder containing the subfolders Databasesand FileSystems
Opening Raven.Server.exe.config and changing the value for the settings Raven/DataDirand Raven/FileSystem/DataDir
Starting the Ravendb service again
Tricky part: going to some (not all) databases using Raven Studio and choosing Settings > Database Settings and changing the value here (again) for Raven/DataDir. So apparently, somehow, for some of my databases, this value was overridden in some metadata for the db itself rather than using the tilde to look relatively to the global setting (although the actual db or db definition or something was being loaded correctly, since I could even see this setting/value)
So far so good. But here the problem:
Apparently, too, for some filesystems (again not all), Ravendb seemed to think, their "data-data" was still in the old location (again, the actual filesystem metadata seemed to be loaded from the new location). But alas, filesystem do not have something similar to Database Settings in Raven Studio where I could change this data-dir, probably overridden here too.
The way I know the filesystems' data is assumed to still be in the old location, is that I can see new folders being created in the old location with the name of the respective filesystems.
I tried going to the system db (Main Window > Manage Your Server > To System Database), but the file-systems do not appear here.
So my question is: how can I change or set the Raven/FileSystem/DataDir setting for a single filesystem?
Eureka, I found this out:
The error was indeed, that for some reason, my filesystems do not appear in the system db when viewed in Raven Studio. I realized this, because the status-bar in the system db said 40 documents, but fewer were visible in the list. This must definitely be a bug in Raven Studio.
The solution: In system db, put my mouse cursor in the quick-goto-/search-field in the top ("Go to document") and typed Raven/FileSystems/ and from here on, the autocomplete would show me the available filesystems. Choosing the correct filesystem, I was now able to edit the (indeed overridden) path to the filesystem, which was set to an absolute path.
Note, that in general you should definitely use a path relative to the Raven/DataDir and Raven/FileSystem/DataDir settings, like e.g. ~\filesystems\my-db to more easily be able to move all dbs and fs'es around collectively.
I just moved a custom built CMS over to a live server (it was on the development server) because it is easier to set up RSS. The problem is that none of my relational mappings work anymore, despite me changing the application.cfclocation to reflect the new path. It uses an absolute path, as well. The setup is like so:
F:\...\cmsRoot\com\dac (this is the original path)
F:\...\cmsRoot\admin\com\dac (this is the path on the new server. The only difference is the extra layer for the admin folder; the drive letters are the same)
The Application.cfc and most pages are located in the cmsRoot and cmsRoot\admin folders, respectively. The dac folders contain my relational CFC files.
Originally, when loading each cfc for the first time Coldfusion would throw an error saying
"Error Occurred While Processing Request
Cannot load the target CFC abc for the relation property abc in CFC xyz
for each relational mapping (I commented them out to make sure every single one had the same problem).
After I added the line <cfscript>ORMReload();</cfscript> to the beginning of each CFC file, I could get past this error and access the login page just fine. However, now I get an error any time I try to create an entity:
Mapping for component abc not found.
The first instance that calls it (and throws the error) looks like this:
objectABC = EntityToQuery(EntityLoad("abc", {ActiveInd=1}));
I've already searched for any related problems on stackoverflow already, and it helped me fix the original error by adding ORMReload() calls. However, that doesn't solve the current problem. I've changed the mapping for the CFC's (in the Application.cfc) to use a relative path, and that did not help either (since I figured it was likely a mapping issue). I also checked folder permissions to make sure they matched, since one user said that fixed their problem. Both folders have the same permissions, as well.
Here's any useful Application.cfc info, if that helps:
this.ormsettings = { cfclocation = ["F:\...\cmsRoot\admin\com\dac", "F:\...\cmsRoot\admin\com"]
, dialect="MicrosoftSQLServer"
, eventHandling = true
};
The only difference I can find between the Application.cfc files on the two servers is the filepaths. Database is set up correctly, and the pages themselves have no problems (that I know of).
Another thing I've found is that commenting out any relational mappings causes everything to load correctly (minus any objectABC.getXYZ() calls since I removed those properties).
I have also restarted the Coldfusion application server, but there were no noticeable differences.
Is it possible that an Application.cfc farther up in the file structure is overriding any cfclocation settings I set up? I didn't think this would be the case, but since nothing seems amiss with my Application.cfc, I am out of ideas. And the application.cfc/.cfm lookup order (under "Settings" in the CFIDE administrator) is the same for both; set as default.
I have also tried removing the extra folder layer (so all mappings are the same), but the error is identical.
Update: By adding a specific mapping for /cmsRoot (to F:...\cmsRoot), I get a new error that the components are not persistent. However, all my cfc's start like this:
component persistent = "true" entityName = .....
Is there a reason why Coldfusion would think the entities aren't persistent even though I defined it otherwise? And yes, I have used ormReload() to make sure it is updated properly.
The solution I found was to add a specific mapping to the cmsRoot folder by using application.mappings['\cmsRoot'] = 'F:\...\cmsRoot'; in my Application.cfc file.
I had some old ormReload() calls at the top of all the .cfc files because that allowed some things to work; by deleting those calls it now loads properly.