I am new to liquibase, and want to check if this is the ideal tool to handle this. Please suggest others outside of liquibase too, if appropriate.
Usecase:
We have a property file that the user can modify. We are looking to solutions on utilizing liquibase to be able to maintain both the user changes as well as the new changes. Is this possible with liquibase? What would the workflow look like?
// Version 1; Release 1
<a>
<b foo="1"></b>
<a>
Now, we roll out Release 1 and the client A has modified foo to be 2 for their purposes; this is what the version 1 now is for the client A after they made their changes. Client B did not do any changes.
// Version 1; Release 1 - at client A
<a>
<b foo="2"></b>
<a>
// Version 1; Release 1 - at client B
<a>
<b foo="1"></b>
<a>
Now in Release 2, we update foo to be 10, and add a new variable 'goo'.
So, this is how Version 1 is enhanced
// Version 2; Release 2
<a>
<b foo="10" goo="2"></b>
<a>
Now, when we upgrade the client to version 2, we want to keep the client at their value of foo if it is changed, else switch it to 10. also 'goo' needs to be added.
So, after upgrade, the client file is expected to look like this:
// Version 2; Release 2 - at client A
<a>
<b foo="2" goo="2"></b>
<a>
// Version 2; Release 2 - at client B
<a>
<b foo="10" goo="2"></b>
<a>
======================
The solution we were thinking is to persist this xml into a table, and have liquibase version it.
Prior to upgrading the client B, do a dump of their xml to liquibase, and somehow find out that it is different from what was installed.
Now, using some diff, enable the above result.
Need some ideas with this please? TIA!
Using PreCondition would work - it can detect user changes without too much complexity as long as you only have a few changes, ie an edge case like what you've described. If it becomes more complex, you may need a different solution or may need to write custom preconditions to accommodate the increased complexity. Documentation: https://docs.liquibase.com/concepts/changelogs/preconditions.html
I also found another question that looks like it might be similar to what you're asking. Link: Can Liquibase handle multiple schemas managed by the same application?
Answer From Nathan Voxland, Liquibase co-founder:
Liquibase can handle objects within multiple schemas and can also manage creating additional schemas as well.
When you connect to the database, Liquibase will create a DATABASECHANGELOG table in the default schema and that schema needs to exist. That table tracks which changeSets have executed, and anything that can be done through SQL can be done within your changeSets.
There are built-in tags for things like createTable, addColumn etc which will make changes in the default schema, but they all have tags such as tableSchemaName that can be used to target the object to a different schema.
If you want to make changes for which there are not built-in tags, you can always use the "sql" tag and specify whatever sql you want, such as create database additional_info
Related
I have some records in a CMS that include HTML fragments with custom tags for a widget tool. The maker of the CMS has apparently updated their CMS without providing proper data conversion. Their widgets use keys for layout based on screen width such as block_lg, block_md, block_sm. The problem kicks in with the fact they used to have a block_xs and they have now shifted them all -- dropping the block_xs and instead placing a block_xl on the other end.
We don't really use these things, but their widget configurations do. What this means for us is the values for each key are identical. The problem occurs when the updated CMS code is looking for the 'block_xl' in any widget definition tags, it can't find it and errors out.
What I'm thinking then is that the new code will appear to 'ignore' the block_xs due to how it reads the tags. (and similarly, the old code will ignore block_xl) Since the values for each are identical, I need to basically read any widget definition and add a block_xl value to it matching the value of [any one of] the other width parameters.
Since the best place order-wise would be 'before' the block_lg value, it's probably easiest to do it as follows:
Replace any thing matching posix style regex matching /block_lg(="\d+,\d+")/ with: block_xl="$1" block_lg="$1"
Or whatever the equivalent of that would be.
Example of an existing CMS block with multiple widget definitions:
<div>{{widget type="CleverSoft\CleverBlock\Block\Widget"
widget_title="The Album" classes="highlight-bottom modish greenfont font52 fontlight"
enable_fullwidth="0" block_ids="127" lazyload="0"
block_lg="127,12," block_md="127,12," block_sm="127,12," block_xs="127,12,"
template="widget/block.phtml" scroll="0" background_overlay_o="0"}}</div>
<!-- Image Block -->
<div>{{widget type="CleverSoft\CleverBlock\Block\Widget"
widget_title="What’s Your Favorite Cover Style?"
classes="zoo-widget-style2 modish grey font26 fontlight"
enable_fullwidth="0" block_ids="126" lazyload="0"
block_lg="126,12," block_md="126,12," block_sm="126,12," block_xs="126,12,"
template="widget/block.phtml" scroll="0" background_overlay_o="0"}}</div>
What I would prefer to end up with from the above (adding block_xl):
<div>{{widget type="CleverSoft\CleverBlock\Block\Widget"
widget_title="The Album" classes="highlight-bottom modish greenfont font52 fontlight"
enable_fullwidth="0" block_ids="127" lazyload="0"
block_xl="127,12," block_lg="127,12," block_md="127,12," block_sm="127,12," block_xs="127,12,"
template="widget/block.phtml" scroll="0" background_overlay_o="0"}}</div>
<!-- Image Block -->
<div>{{widget type="CleverSoft\CleverBlock\Block\Widget"
widget_title="What’s Your Favorite Cover Style?"
classes="zoo-widget-style2 modish grey font26 fontlight"
enable_fullwidth="0" block_ids="126" lazyload="0"
block_xl="126,12," block_lg="126,12," block_md="126,12," block_sm="126,12," block_xs="126,12,"
template="widget/block.phtml" scroll="0" background_overlay_o="0"}}</div>
I know how to do it in php and if necessary, I will just replace it on my local DB and write an sql script to update the modified records, but the html blocks can be kind of big in some cases. It would be preferable, if it is possible, to make the substitutions right in the SQL but I'm not sure how to do it or if it's even possible to do.
And yes, there can be more than one instance of a widget in any given cms page or block. (i.e. there may be a need for more than one such substitutions with different local 'values' assigned to the block_lg)
If anyone can help me do it in SQL, it would be greatly appreciated.
for reference, the tables effected are called cms_page and cms_block, the name of the row in both cases is content
SW
I have a JCR content repository implemented in ModeShape (4.0.0.Final). The structure of the repository is quite simple and looks like this:
/ (root)
Content/
Item 1
Item 2
Item 3
...
Tags/
Foo/
Bar/
.../
The content is initially created and stored under /Content as [nt:unstructured] nodes with [mix:shareable] mixin. When a content item is tagged, the tag node is first created under /Tags if it's not already there, and the content node is shared/cloned to the tag node using Workspace.clone(...) as described in the JCR 2.0 spec, section 14.1, Creation of Shared Nodes.
(I don't find this particularly elegant and I did just read this answer, about creating a tag based search system in JCR, so I realize this might not be the best/fastest/most scaleable solution. But I "inherited" this solution from developers before me, so I hope I don't have to rewrite it all...)
Anyway, the sharing itself seems to work (I can verify that the nodes are there using the ModeShape Content Explorer web app or programatically by session.getRootNode().getNode("Tags/Foo").getNodes()). But I am not able to find any shared nodes using a query!
My initial try (using JCR_SQL2 syntax) was:
SELECT * FROM [nt:unstructured] AS content
WHERE PATH(content) LIKE '/Tags/Foo/%' // ISDECENDANTNODE(content, '/Tags/Foo') gives same result
ORDER BY NAME(content)
The result set was to my surprise empty.
I also tried searching in [mix:shareable] like this:
SELECT * FROM [mix:shareable] AS content
WHERE PATH(content) LIKE '/Tags/Foo/%' // ISDECENDANTNODE(content, '/Tags/Foo') gives same result
ORDER BY NAME(content)
This also returned an empty result set.
I can see from the query:
SELECT * FROM [nt:unstructured] AS content
WHERE PATH(content) LIKE '/Content/%' // ISDECENDANTNODE(content, '/Content') works just as well
ORDER BY NAME(content)
...that the query otherwise works, and returns the expected result (all content). It just doesn't work when searching for the shared nodes.
How do I correctly search for shared nodes in JCR using ModeShape?
Update: I upgraded to 4.1.0.Final to see if that helped, but it had no effect on the described behaviour.
Cross-posted from the ModeShape forum:
Shared nodes are really just a single node that appears in multiple places within a workspace, so it's not exactly clear what it semantically means to get multiple query results for that one shareable node. Per Section 14.16 of the JSR-283 (JCR 2.0) specification implementations are free to include shareable nodes in query results at just one or at multiple/all of those locations.
ModeShape 2.x and 3.x always returned in query results only a single location of the shared nodes, as this was the behavior of the reference implementation and this was the feedback we got from users. When we were working on Modeshape 4.0, we tried to make it possible to return multiple results, but we ran into problems with the TCK and uncertainty about what this new expected behavior would be. Therefore, we backed off our goals and implemented query to return only one of the shared locations, as we did with 2.x and 3.x.
I may be wrong, but I'm not exactly sure if any JCR implementation returns multiple rows for a single shared node, but I may be wrong.
I've used Joel Krooswyk's Print All Backlog Story Cards solution for printing all stories in a backlog.
What I'd like to do is to extend this to have each card print the name of the parent feature that the card belongs to so I can print them all up and lay them on a table for a collaborative estimation session.
The issue is, I'm having trouble finding how to do it.
A snippet of his code in question:
queryArray[0] = {
key: CARD_TYPE,
type: 'hierarchicalrequirement',
query: '((Iteration.Name = "") AND (Release.Name = ""))',
fetch: 'Name,Iteration,Owner,FormattedID,PlanEstimate,ObjectID,Description,UserName',
order: 'Rank'
};
I can't seem to find the element to fetch!
Parent was listed on an example queries page(intended for use in the browser query functionality), with Parent.Name containing the actual text but so that hasn't worked - trying to find a reference that is clear about it seems to be eluding me.
I've looked at the type definition located at:
https://rally1.rallydev.com/slm/webservice/v2.0/typedefinition/?fetch=ObjectID&pagesize=100&pretty=true
Going to the hierarchical requirement's type definition from that page indicates it has a Parent field in one form or another.
I'm not even sure that that one will solve what I'm looking at.
A bit stuck, and I'm not sure what I'm trying to do is even possible with the hierarchical requirement object type.
Note: I assume even if I do find it I'll need to add some code to deal parentless stories- not worried about that though, that's easy enough to deal with once I find the actual value.
Many thanks to anyone who can help :)
I modified Joel's app to include PI/Feature's FormattedID to the cards when a story has a parent PI/Feature.
You may see the code in this github repo.
Parent field of a user story references another user story.
If you want to read a parent portfolio item of a user story, which is a Feature object, use Feature attribute or PortfolioItem attribute. Both will work:
if (data[i].PortfolioItem) {
//feature = data[i].PortfolioItem.FormattedID; //also works
//feature = data[i].Feature.Name; //also works
feature = data[i].Feature.FormattedID;
} else {
feature = "";
}
as long as the version of API is set in the code to 1.37 or above (up to 1.43).
PrintStoryCards app is AppSDK1 app.
1.33 is the latest version of AppSDK1.x
1.29, which the app is using is not aware of PortfoilioItems.
PortfolioItem was introduced in Rally in WS API version 1.37.
See API versioning section in the WS API documentation .
If you want to access Portfolio Items, or other features introduced in later versions of WS API up to 1.43 this syntax will allow it.
<script type="text/javascript" src="/apps/1.33/sdk.js?apiVersion=1.43"></script>
This has to be used with caution. One thing that definitely will break is around calculations of timebox start and end dates. That's why many legacy Rally App Catalog apps are still at 1.29.
This is due to changes in API Version 1.30.
Note that this method of setting a more advanced version of WS API for AppSDK1 does not work with v2.0 of WS API.
You should be able to add PortfolioItem to your fetch. Parent is the field used if the parent is a story. PortfolioItem is the field used if the parent is a Feature (or whatever your lowest level PI is).
Then in the results you can just get it like this:
var featureName = (story.PortfolioItem && story.PortfolioItem.Name) || 'None';
Is it possible for me to declare a dependency using a dynamic revision while restricting the status of the retrieved artifact? For example, I want to define a version range, something like "[1.0,1.1[", but I don't want artifacts with a status of integration, only milestone or release. So I want version 1.0.5 if it has a status of "release" even if there's a version 1.0.6 with a status of "integration."
I know about latest.status, but that's not really what I want: I need to define an upper and lower limit on the revision.
Maybe the solution is to define your own version-matcher see http://ant.apache.org/ivy/history/latest-milestone/settings/version-matchers.html
I used it (in ivysettings.xml) to make this:
<!-- Matcher for build with given build number
It assumes the version number is on the form
#.#__.# where the lastet '.#' is the build number. -->
<version-matchers usedefaults="true">
<pattern-vm>
<match revision="build_number" pattern="[\d\.]+\.${buildnumber}" args="buildnumber" matcher="regexp"/>
</pattern-vm>
</version-matchers>
You can call it in you build script by setting the revision attribute like 'revision="build_number(${prop.buildnumber})"'
Thanks for asking this question, rsteele. I had a similar question and here is the solution I am using. It works if your range corresponds to sub-revisions:
The easiest way to present this is with an example:
<dependency org="com.acme" name="wigdet" branch="1" rev="latest.milestone">
1/ivy-1.0.xml: status="integration"
1/ivy-1.1.xml: status="milestone"
1/ivy-1.2.xml: status="integration"
The dependency resolves to 1.1.
This works for me but I am not entirely happy with it and I hope someone can point out a better way or poke holes in it:
branch seems appropriate because com.acme actually has a branch in version control which corresponds to version 1.
on the other hand branch seems inappropriate because "1" is part of the revision, and perhaps branch is more useful in other ways.
this doesn't solve the more general problem posed by rsteele.
My application has 5 plugins. Each plugin has a perspective of it's own and hence each perspective extension definition is under individual plugin's plugin.xml.
Now, I want to control the order in which these perspectives appear in my application. How to do it?
There is one main plugin that holds "ApplicationWorkBenchAdvisor.java". This has initialize() method in which I am iterating through the perspective registry using
PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();
and then appending perspective ids in a comma separated fashion to a String variable (pbar) which is used later like this.
PlatformUI.getPreferenceStore().setDefault(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
PlatformUI.getPreferenceStore().setValue(IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS, pbar);
When iterating thourgh the perspective registry, I can compare perspective ids and sort it(when adding to 'pbar' by comparing ids) the way I want it to appear but, I don't want to do this ordering here as it appears like a dirty way.
Is there any other place where we can fix the order in which perspectives appear? (Each perspective resides in different plugin).
ADDED
1) Could we also control the ordering in the perspective switcher?
2) Is there a way to control entry into perspective registry to in inflict the desired order. If not could we write back into perspective registry?
If your application is encapsulated as an eclipse product, you may tweak the plugin.properties/plugin_customization.ini file.
(file referenced by the 'preferenceCustomization' property in your product extension point.)
This file is a java.io.Properties format file. Typically this file is used to set the values for preferences that are published as part of a plug-in's public API.
(Example of such a file for org.eclipse.platform)
So if the string representing the order of perspective can be referenced as a property, you can define the default order in there.
Since the source code of IWorkbenchPreferenceConstants mentions:
/**
* Lists the extra perspectives to show in the perspective bar.
* The value is a comma-separated list of perspective ids.
* The default is the empty string.
*
* #since 3.2
*/
public static final String JavaDoc PERSPECTIVE_BAR_EXTRAS = "PERSPECTIVE_BAR_EXTRAS"; //$NON-NLS-1$
Maybe a line in the plugin_customization.ini file:
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
would allow you to specify that order without having to hard-code it.
Additional notes:
IPerspectiveRegistry (or PerspectiveRegistry) is not made to write anything (especially for perspective defined in an extension)
Ordering may be found in the state of the workbench (stored in the workspace and then restored when its launched again, .metadata/.plugins/org.eclipse.ui.workbench/workbench.xml)
Do you confirm that:
IPerspectiveRegistry registry = PlatformUI.getWorkbench().getPerspectiveRegistry();
IPerspectiveDescriptor[] perspectives = registry.getPerspectives();
is not in the right order when the plugin_customization.ini does define that order correctly ?
Liverpool 5 - 0 Aston Villa does confirm that (in the comments), but also indicates the (ordered) ini file entries internally get recorded into preference store, which means they can be retrieved through the preference store API:
PatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS)
Liverpool 5 - 0 Aston Villa then add:
perspective registry (the initial "PlatformUI.getWorkbench().getPerspectiveRegistry().getPerspectives();" bit) remains unaltered (and unordered).
But, you still can "readily access to ordered list of perspectives" through preference store.
So, for other tasks, instead of iterating though perspective registry (which is still unordered), we can use the ordered variable that stores list of ordered perpective ids.
.
.
.
.
Note: another possibility is to Replace the Perspective-Switcher in RCP apps
=> to:
You can more easily define the order in a menu or in buttons there.
Extreme solution: re-implement a perspective switcher.
To sum up all the observations and findings,
1) It is not possible to alter entries in the perspective registry. It is read-only.
2) To make perspective appear in the order that we want on perspective bar, we can achieve it by adding an entry in plugin_customization.ini (or preferences.ini) as shown below.
org.eclipse.ui/PERSPECTIVE_BAR_EXTRAS=perspectiveId1,perspectiveId2,perspectiveId3
3) If we want to fetch this ordered list, we can't fetch it directly. But as this ini file entry internally gets recorded in PreferenceStore we can fetch the same value from PreferenceStore using the following API as shown below.
PlatformUI.getPreferenceStore().getDefault(
IWorkbenchPreferenceConstants.PERSPECTIVE_BAR_EXTRAS);
Why would someone need to access the entry defined in ini file at all?
Well, in my case I had a view in which i had to display links to every perspective. As my perspective bar was sorted in desired order, I also wanted to maintain the same order in my view while displaying links to perspectives.
4) There is no known way to inflict the same sort order in the display of default perspective switcher. While a new custom perspective switcher can be written to achieve the desired effect.