We've got Localsolr (2.9.1 lucene-spatial library) running on Solr 1.4 with Tomcat 1.6. Everything's looking good, except for a couple little issues.
If we specify fl=id (or fl= anything) and wt=json it seems that the fl parameter is ignored (thus we get a lot more detail in our results than we'd like).
If we specify fl=id and leave out wt=json (which defaults to returning xml results), we get the expected fields back. We'd really prefer to use wt=json because the results are easier for us to deal with (also, the same issue also arises with wt=python and wt=ruby).
Ideas? Known issue? Workarounds?
Related
I am integrating SQL-Connection to one or our existing Siemens S7-1200 PLCs right now.
After copying a Function Block from a working project, one of the data types has changed and is causing trouble now.
Original:
Copied FB:
Does anybody know, how to fix this?
Someone in the Siemens-Forum could answer my question right away.
Leaving his answer here for the next person with my problem :
With the introduction of the OUC library in version V4.x, the TCON instruction, among other things, has changed. Try to update the program on the CPU. In this case, the prerequisite is that the CPU must have at least firmware version V4.1. There is also the risk that translation errors will occur in other places where the older versions were previously used. In this case, the PLC code would have to be adjusted accordingly.
I'm trying to use this database with react-native. First of all, i've found out that it can't retrieve plain objects - i have to retrieve all of the properties in the desired object tree recursively. And it takes about a second per object (~50 numeric props). Slow-ish!
Now, i've somehow imported ~9000 objects in it (each up to 1000 chars including titles). Looks like there is no easy ay to import it, at least it is not described in docs. Anyway, that's acceptable. But now i've found out that my database size (default.realm) is 3.49GB (!). The JSON file, which i was importing is only 6.5mb. I've opened default.realm with Realm Browser and it shows only those ~9000 objects, nothing else. Why so heavy?
Either, i don't understand something very fundamental about this database or it is complete garbage. I really hope i'm wrong. What am I doing wrong?
Please make sure you are not running in chrome debug mode. This is probably why things seem so slow. As far as the file size issue goes, it would be helpful if you posted your code to help figure out why that is happening.
I have a network path that contains hundred of thousands .wav files. When I do the following:
FileBuffer = Dir$("\\MEDIASERVER\*.wav", FileAttribute.Archive)
The line freezes forever. I have literally let it run a day, and it never returns with execution. I then decided to test the symptom with a dir command in DOS. Same symptom.
I then wondered if I would get the same symptom if I added a prefix to the search pattern narrowing my results. I did this in DOS:
DIR 0009*.wav
Worked like a charm. So, armed with this knowledge, I went back to my VB.NET project and applied a similar solution:
FileBuffer = Dir$("\\MEDIASERVER\0009*.wav", FileAttribute.Archive)
Doesn't get stuck, actually does the search. But I was surprised by the first result:
FileBuffer came back with the following value:
003925034541228334146804222014065036AM005020MIF.wav
This does not match the pattern I asked for. Can someone tell me what I am doing wrong? Is there a known bug with DIR$? Is there a way to achieve what I want without enumerating 100% of the files in the network share?
Additional Information if it's relevant:
Developement Machine: Windows 7 Pro, VS 2013 Pro
Network Server: Linux Centos 5.0 (I have the same issue with a network drive running Windows 7 Pro).
Thanks in advance.
Sorry for just posting the question, and already getting the answer. The question about whether or not it worked properly in DOS helped narrow my troubleshooting. I came across a couple of pages on the net stating that DIR will come back with unexpected results. They state that it's because of the 8.3 naming convention. I then decided to see if there was any other constraints I could add to my program. I changed the pattern to:
DIR \\MEDIASERVER\0009*MIF.wav
And now I am getting the expected results. This cannot be because of the 8.3 Naming convention though. It's something else, but at least I got this working.
Thanks for your time.
I can't really tell what happened and can't remember if I had upgraded 2.2.1 to 2.2.2(my project is 2.2.2), plus It was fine like 2-3 weeks ago, but I think that one of the reason that messed my whole JSON was from upgrade? (I don't know how to downgrade), but I don't want to mess any fonts in my project.
Anyway, when I call an controller/action, It render as JSON, but take a look at my piece of JSON:
Repeat this like 100x.
{"_ref":"../../../..","class":"proj.State"},"stateId":1,"normalizedName":"Something","capital":false,"name":"Something"},"state":1},{"attached":true,"capital":false,"errors":{"errors":[]},"handler":
{"class":"org.codehaus.groovy.grails.orm.hibernate.proxy.GroovyAwareJavassistLazyInitializer","entityName":"proj.City","identifier":1,"implementation":
{"_ref":"../../../../../..","class":"proj.City"},"persistentClass":"proj.City","readOnly":false,"readOnlySettingAvailable":true,"session":{"JDBCContext":
{"class":"org.hibernate.jdbc.JDBCContext","connectionManager":{"aggressiveRelease":false,"autoCommit":true,"batcher":
{"class":"org.hibernate.jdbc.BatchingBatcher"},"class":"org.hibernate.jdbc.ConnectionManager","connection":{"autoCommit":true,"catalog":"DEVDB","class":"com.sun.proxy.$Proxy24"
And in my grails-app/conf/spring/ contains my 2 SQL and I don't know why they come up with my JSON together, It didn't happened before.
What the cause could be?
Reflection from domains, found that he keeping searching all domain from the properties address: company.address and render this as json and give me all the crap.
I just stumbled upon an interesting bug... Still trying to figure out what is exactly happening. Maybe you can help.
First, the context. I'm currently building yet another man to html converter (for some reasons I won't motivate here, but I need it).
So, have a look at the screenshot below (see the link), more precisely at the outlined spots. See? On the upper shell, I have < ; and > ;, that is, escaped html.
While on the shell below I have < and > directly.
But as you can see (or do I seriously need looking glass ?), the command man 2 semget | webmanneris the same on both sides, as is the which webmanner. The two are executed roughly at the same moment, with no modification made to the script between.
[Oops, cannot post pictures just yet... Here comes the link]
http://aspyct.org/media/webmanner-bug.png
But the shell below is older (open about 1 hour ago). Newer shells all print out < ;. So my first guess was that it somehow had a cached reference to the old inode of the file, or old blocks or whatever.
So I modified parts of the script, at the start and then at the end, to print different messages. And, surprise, the message shown up on both terminals. But still, same difference between < ; and <.
I'm confused... How to explain that behavior? I'm working on a OSX 10.8 (Mountain Lion)
EDIT: OK, there is one big difference: the shell below uses ruby 1.9.3, while above is 1.8.7. Is there any known difference in string handling between the two versions ?
Are you using the htmlentities library? If so then this bug fix is probably what you are seeing
Ruby 1.9.3 has slightly different behaviour to 1.9.2: the result of
encode was not ASCII even when it only contained ASCII characters.
This may not be important, but this change makes both versions produce
the same result.
https://github.com/threedaymonk/htmlentities/commit/46dafc959de03a02d0c1705bef7f1b157b350025