I have problem with etcd v2. I am creating configuration management which is using etcd v2 as K/V store. Now I do need version history as well but looks like v2 does not support it at least not straight out from the box.
I have been reading their API and at least v3 do have version/revision in response. Is there any way I could get version into v2 response as well?
Only solution currently I find is to use custom suffix with version numbers. Also using running number (POST instead of PUT) but looks like it is more as ID than version (every new or modified will increase that number)
Any ideas? Custom database to store previous versions only proper solution?
Found out that v2 does not support versions (feature in v3). I created own logic to handle versions.
Related
I am checking out the documentation on IBM Cognitive Services and have come across two ways of connecting to my existing workspace.
Version 1
Version 2
My question is which of them is the one that needs to be used. They both appear to work but I am not sure which one to go with. Is there another API that is latest perhaps?
The latest version API will be on the release notes and the API reference.
https://www.ibm.com/watson/developercloud/doc/conversation/release-notes.html
Using an earlier version number will disable later features, but any workspace created with a later version may not be backward compatible, and results may be unpredictable.
There is currently no way to create earlier workspace structures once there has been an update to the version. But if you have older workspaces, they will still remain compatible.
Is there a way to get all versions and related File of single document
Suppose that I have published document 'abcd' with version 1.0. Then later, I modify the document and publish it with 1.5 and i want both version in java so is ther any possible way to get all documents with diffrent version in nuxeo.
Yes, CoreSession.getVersions will do that for you. There are also variants of this API that returns just document references or a bit more information related to each version. You should peruse the CoreSession API to know more.
I am trying to upgrade my app from GAE 1.8.1 to 1.9.3, apparently there is one major issue with retrieving child records in any one to many relationship I have.
In the old version I was using datanucleus JDO version 1 and everything worked fine. Now I am using version 2.
After the upgrade I can only retrieve parent objects (the child are nulls), although when I create new data it seems to be working fine.
I checked how the new data looks like in the database viewer, and it seems that the one-to-many column in the class of the old data is labeled as "missing".
If I create new data the data is filled with some index information.
I will appreciate any help
Update
Apparently datanucleus JDO version 2 is not fully backward compatible to version 1. If you're going to consider an upgrade verified the data relationships were not broken (like mine did)
My current solution is to stay with version 1 and use the newest GAE SDK (which seems to be working well)
Apparently datanucleus JDO version 2 is not fully backward compatible to version 1. If you're going to consider an upgrade verified the data relationships were not broken (like mine did)
My current solution is to stay with version 1 and use the newest GAE SDK (which seems to be working well)
I have Solr 4.10 and I have collection on it with solorconfig.xml has the value for <luceneMatchVersion> as follows:
<luceneMatchVersion>4.7</luceneMatchVersion>
Is this correct? I saw other examples that has values such as LUCENE_35 What I need to know also, how could I express LUCENE_xx from my current Solr version?
You should use:
<luceneMatchVersion>4.10.4</luceneMatchVersion>
I recommend you to check your current solr version, in my case was 4.10.4.
if you are going to reindex, then both numbers should match. The only reason you might want to have them different, is if you had and index created with say Lucene 4.7, then you would have
<luceneMatchVersion>4.7</luceneMatchVersion>
Then, you upgrade lucene to 4.10.
Now, if among the changes in between 4.7 and 4.10 there are things that work differently regarding analysis (you get the same sentence analysed in both versions and get different output as a result), then, you might want to keep the version number at 4.7, otherwise some queries that contain affected terms might not work (as they were analysed at index time in a different way than at query time). You have to asses how critical that issue might be.
That is why the recommendation is to upgrade, change the setting to the current number, and reindex. This way you are sure to avoid any issue.
If anyone is using Drupal, the Search API Solr (search_api_solr) module has config templates by version in /sites/all/modules/search_api_solr/solr-conf/.
The template README.md states the following:
The solr-conf-templates directory contains config-set templates for
different Solr versions.
These are templates and are not to be used as config-sets!
To get a functional config-set you need to generate it via the Drupal
admin UI or with drush solr-gsc. See README.md in the module
directory for details.
The module's README.md lists these instructions:
Make sure you have Apache Solr started and accessible (i.e. via port 8983). You can start it without having a core configured at
this stage.
Visit Drupal configuration (/admin/config/search/search-api) and create a new Search API Server according to the search_api
documentation using "Solr" as Backend and the connector that
matches your setup. Input the correct core name (which you will
create at step 4, below).
Download the config.zip from the server's details page or by using drush solr-gsc with proper options, for example for a server named
"my_solr_server": drush solr-gsc my_solr_server config.zip 8.4.
Copy the config.zip to the Solr server and extract.
I generated a config file for 8.x, and it uses this:
<luceneMatchVersion>${solr.luceneMatchVersion:LUCENE_80}</luceneMatchVersion>
I have a test app on app engine.
I incremented its version and deployed again
now If I modify some data in one version, it is written on datastore that 2nd version uses (because version point to same store)
how can I disable the version, without deleting it?
There's only one datastore that's common to all versions. It's not like each version has its own datastore.
You can set a default version, but you can't prevent anyone from directly forcing a version by going to http://version.appid.appspot.com
you could use namespaces to separate the data between versions.
https://developers.google.com/appengine/docs/python/multitenancy/overview