I've got a bunch of XML messages in a PostgreSQL 9.1.3 table, with a column content of type XML). They're not all the same "type", so I'm trying to extract the root type using a query like this:
SELECT xpath('name(/*)', content) FROM message;
as recommended by this answer to a similar SO question.
A sample message is:
<?xml version="1.0" encoding="UTF-8"?>
<WML version="6" xmlns="http://example.com/schemas/WML">...</WML>
For which case I'd hope to get the result '{WML}'. Unfortunately it just returns an empty array. Adding the namespaces parameter to xpath, or removing the namespace from the message, does not help.
A discussion on the PostgreSQL mailing lists seems to explain it as a bug in XPath handling in PostgreSQL. However that was in 2008, and a look at the PostgreSQL source shows that piece of code was changed in 2009. I'm not a PostgreSQL developer so I'm not confident that the bug is or is not a factor in my case.
But I'm wondering if there's a workaround, such as an alternative XPath expression that might work? I'd prefer not to have to resort to regular expressions to parse XML, though if you can suggest a short, punchy, robust RE then it would be better than nothing.
Clearly, this has not yet been solved as of June 2011.
I found this thread on pgsql-hackers that describes your problem exactly.
I don't know of a workaround for older versions, but this is fixed in PostgreSQL 9.2, so that's great.
(The likeliest workaround would likely to have been to write a function to parse the XML manually, but I'm glad I don't have to resort to that now!)
Related
I cannot work out where this doco might be - i'm assuming they do have something on it. I realise this is a dead simple question, but no amount of searching is bringing this up for me.
Bing/DuckDuck etc search cannot find anything particularly relevant, and the only w3c.org links I followed went to "functions", which apparently "select" isn't.
EDIT (Apologies for ambiguity) I am looking for the definition of something along the lines of :
<xsl:variable name="variableName" select="some/path/here" />
That is an XSLT variable. Like many other XSLT elements, it has a select attribute that takes an XPath expression as a value. The value of this attribute just typically happens to be an XPath expression, but the attribute itself isn't directly related to XPath, so you won't find it documented in the XPath spec.
You code fragment is in XSLT, so the specification you want is either "XSLT 1.0" or "XSLT 2.0", which you can find very easily by using these as Google search terms. The value of the select attribute is an XPath expression, so you may also want the XPath 1.0 or XPath 2.0 specification; these can be found the same way.
I am currently migrate some legacy data from CRM 4.0 to CRM2011, however, there is big barrier on the Many-to-Many relationship importing, I have search for the solution and get this from codeplex http://crm2011manytomany.codeplex.com/discussions/433816,
when I importing data, it keep get 'Issues on line 1 - line has 1 instead of 2' error,
any advise on it
Thanks
I don't know how that tool is working but I found this blog that covers how to do an import of many-to-many. Other than that it's cusom coding that will solve this issue I'm afraid. Write a program that does what you want, it will take some time and it's not a trivial task but it might be the only way.
The Codeplex you mention actually works, I just tested it.
There is however an issue regarding the file encoding format. As a workaround you can copy past your csv content within notepad++, use encoding UTF8 and save it -> the import will work fine then.
We are maintaining an application that heavily relies on DOM4J and Xpath. Once in a while we see a strange behaviors with results of XPath execution via DOM4J: The text result would simply be truncated.
We tried applying the recommendation provided here: http://www.mail-archive.com/dom4j-user#lists.sourceforge.net/msg02688.html
It seems the problem occurs less frequently but it still manifests itsself. Last time we got it, it was after applying Xpath on a the clone of a document parsed as indicated by the previous link.
This also seems to be similar to the issue mentioned here: Use of text() function when using xPath in dom4j
As far as i know lucene(.net) doesn't support the wildcard at the beginning of a searchterm
--> http://lucene.apache.org/java/2_0_0/queryparsersyntax.html
"Note: You cannot use a * or ? symbol as the first character of a search."
for example
*myword
maybe because it's quiet difficult to search "everything" before the searchterm.
Despite that, We are looknig for a way to use the wildcard at the beginning.
Does anyone know if this is possible?
One Thought was asearchterm, bsearchterm, ....z*searchterm
... but that seems a bit random to me.
thanks in advance
Your question is tagged with Lucene.NET so I assume you mean the .NET version rather than the Java version.
Yes, you can have wildcards at the beginning of a search term by via
var queryParser = new QueryParser(LuceneVersion, "content", new StandardAnalyzer(LuceneVersion));
queryParser.SetAllowLeadingWildcard(true);
but you need to be aware of the performance consequences. Find more detailed source code in this blog.
Since Lucene.NET is a port of the Java version, I suspect you could use the same approach for the Java version. I didn't verify this, though.
How can I create or associate a super column to a column in Perl using Net::Cassandra?
I just chatted with the module author and he doesn't understand the question. Then he guessed you want batch_insert which can take a supercolumn.
If that doesn't help, perhaps you step back, try to explain what you want to achieve and rephrase the question.
Best way, IMHO, is to submit a request to add information about super columns into documentation into Net::Cassandra bug tracker.
batch_insert is one way like daxim says; another way is to just use normal insert but specify super_column in the ColumnPath as well as the column_family.
It looks like Net::Cassandra stays pretty close to the thrift api, so this should be useful: http://wiki.apache.org/cassandra/API