my.packages is a custom archetypes package in the src directory. Thousands of items in the Plone instance are added with its types. I want to rename the package as my.package. By simply uninstalling my.packages and installing my.package, I find http://localhost:8080/mysite/myfolder/my-item showing <persistent broken my.packages.content.mytype.MyType instance '\x00\x00\x00\x00\x00Un^'>. Should I have to do migration? Or is there a simple way to fix this issue?
You can create an alias for backward compatibility, by fudzing with sys.modules. Do this in your package __init__.py:
import sys
sys.modules['my.packages'] = sys.modules[__name__]
This way the persistence machinery can find your classes still.
What happens is that when your Archetypes instances are persisted in the ZODB, the persistence machinery stores a module path for the class (a dotted python path such as my.packages.types.foobar.FooBar) in the stored data. When restoring an object from the ZODB, that same path is then used to re-create your instances. When you rename your package, all these references are broken.
With the above trick, the nice thing is that if your object were changed and written to the ZODB again in a transaction, the new module path will be stored. You could thus conceivable cause a write to all your Archetypes instances from this package to make the migration permanent so you can remove the above work-around again.
Related
When I try to delete a class using the "Remove" option in the Jade class browser, I get the error:
"Class xxx cannot be deleted because:
Classes in an SDS Primary database cannot be deleted from the current schema context".
How can I remove a class?
In the context of an SDS environment, you need to version the schema before you can remove a class (using the 'Remove' option via the IDE for the latest schema version).
The re-org used to transition schema versions is then replayed on the SDS environment, as part of which its cached metadata is refreshed to reflect structural changes. I believe class removals is included with this (even if there's no persistent instances), because it'd need to discard the redundant class number.
You will want to use the Jade Schema Loader, with a command file.
According to the JADE Schema Load User's Guide, the syntax for the command file is:
JadeCommandFile
JadeVersionNumber 7.1.00
Commands
Delete Class ErewhonInvestmentsModelSchema::TenderSale
And you load it on your database server using:
jade.exe schema=RootSchema app=JadeSchemaLoader path=d:\jade\system ini=d:\jade\myjade.ini startAppParameters commandFile=d:\temp\DeleteClass.jcf loadStyle=currentSchemaVersion
Be sure to shutdown your database before running the command, or it will not run.
I have an Alfresco module that I would like to have do some cleanup when a new version of it is installed.
In the current situation, an older version of the module created a folder node with custom properties at the root of the repository. We've since decided to have multiple such nodes, and none of them at that location. I'd like to put into the next version of the module code that would run at Alfresco startup, check for the existence of the old node, copy its properties into the appropriate new nodes, and delete the old node.
Is such a thing possible? I've looked at the Bootstrap configuration file, but that appears to only allow one to add things to the repository, not modify or delete them.
My suggestion is that you write a patch. That is a class that implements
org.alfresco.repo.admin.patch.AbstractPatch
Then you can do pretty much anything you want on bootstrap (except executing searches against solr since it wont be available).
Add some spring configuration, take a look at the file patch-services-context.xml for inspiration.
Yes you can do that, probably you missed the correct place in the documentation about that:
If you open Import Strategy you'll find a section Per BootstrapView, you should be using something like REPLACE_EXISTING or UPDATE_EXISTING for your ACP packaged content (if you're using ACPs as your bootstrap importing strategy).
Here is a more detailed description of the UUID Bindings values.
Hope that helps.
You can use patches.
When alfresco server starts it applies patches and executes database updates etc.
Definition :
A patch is a piece of Java code that executes once when Alfresco
Content Services starts. Custom patches can be implemented.
Documentation Link
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
I use an ivysettings.xml file to configure the repositories to use for sbt, which uses Ivy.
However, it's not able to download a particular snapshot which uses unique naming (i.e. date-based naming). It only tries the patterns listed explicitly in my ivysettings.xml file (which makes sense), so it can't see the details in maven-metadata.xml which tell it the filename of the snapshot jar to download.
I tried specifying the version explicitly instead of as a snapshot in Build.scala:
"com.jolbox" % "bonecp" % "0.8.1-20131105.191813-1"
(which would be my ideal solution, because then it would be cached in our maven repository and I'd be guaranteed to always use the same snapshot), but this generated the wrong URL (there should be an 0.8.1-SNAPSHOT in there, but of course there isn't):
http://maven/nexus/content/groups/softwaretools-snapshot-group/com/jolbox/bonecp/0.8.1-20131105.191813-1/bonecp-0.8.1-20131105.191813-1.pom
I then tried specifying the URL explicitly using from, but this didn't work.
I then tried using latest.integration as the version, but that didn't correctly identify the latest version - it thought it was 0.8.0-rc1, which is clearly wrong.
Download the dependency manually and add it to the lib directory of the project (create it if necessary); remove it from the Build.scala file.
How can I able to find the usage of default tables available in drupal.
Is there any documentation available?
For example: there is a table called node. I need to know what is the usage of it and how it acts.
Any suggestions or answers will be helpful and grateful.
Your question is not very clear (the term "usage" is quite ambiguous), but you could install the Devel module. After setting it up it will show, for every page loaded (home page included), which SQL queries are run.
Every module can add tables to the database. A default Drupal install uses core modules, either required ones or those installed as dependencies of the default installation profile. These modules install their own tables.
Each module declares its tables in its implementation of hook_schema. The Schema module use the information from the implementations of this hook to provide a schema documentation.
Most of the time, you shouldn't directly access the database but use the API provided by the modules managing the data. Tables are usually considered private for their modules. New release of a module may change its schema in an incompatible way. Using API is much safer. Unfortunately, sometimes database access is the only option. In these cases, implementation of a data access layer between your code and the database is advised.