Silence "unknown OID 17227: failed to recognize type of 'geography'. It will be treated as String." - postgresql

I'm using columns of type "geography" for some few "point within polygon" queries. They are too few and too simple to bundle a GIS gem, I handle it all on the SQL level.
However, every time Rails boots (rake tasks, console etc), the following warning is spit:
unknown OID 17227: failed to recognize type of 'geography'. It will be treated as String.
I'm fine with "geography" being treated as "String", but the warning triggers warning mails every time a cronjob executes any rake task.
Any idea how I can silence this warning?
Thanks for your hints!

Looking at the source of ActiveRecord, I can answer the question myself:
The warning is hardcoded and therefore can't be silenced by AR configuration. However, RUBYOPT=-W0 gets rid of warnings altogether. This is a big chopper of course, but since I'm still getting those warnings in local development, I can live with a totally warning-less production system.

Since this is the first question/answer that appears given that the title is the error, I would recommend following this answer to fix it: What is the source of "unknown OID" errors in Rails?

Related

Sudden too many errors: methods are undefined

My DES model was working well till I've added a new function (just like many others added before) and the model gave me all these error messages:
I wonder what do these messages mean and what made all of them appear suddenly. I was running the model just before it without any errors. Is there a way I could get my model back? :)
Thank you.
Edit 1:
Here is the newly created function: Newly created function
Given that I've ignored it, and made all the callings of it as comments, then the errors were still appearing. I've closed this model version and opened a backup then created the same function and the whole scenario happened again with the same 94 errors.
Is there something I need to change in the function itself?
The function checks the number of agents in certain parts of the model to stop delay blocks accordingly. That's done by adding variables that increment on exiting of agents and get the difference between them.
Typically this is caused by a syntax error in the new function that you created. See if you ignore this and then compile if it gets fixed.
Most of the time the compiler is smart enough to show you the error, but often if you replace a { with [ or you leave out a { the compiler get very confused and gives you 100s of errors.
If yous still cant find the issue maybe paste the code of your new function in the question.

Xcode Runtime Error log: What does the [#:#] mean in AppName[#:#]?

I got the following runtime error:
2014-12-10 19:26:39.695 Bliss2[21855:994070] Error: object not found for update (Code: 101, Version: 1.5.0)
I assume the [21855:994070] has a meaning.
How do I use it to track down the error in the code?
That is not a "runtime error". It is an NSLog message and has been executed and logged in perfectly good order (e.g. by some third-party code you are using?). Of course the code may then have thrown an exception / aborted, but if it did (and I don't know whether it did), that has nothing to do with the log message itself, except that you're being told first that there's a problem, apparently as a courtesy.
As for the numbers, they probably have nothing to say that will concern you here. The first number is your process number and won't be stable between invocations; it is rarely of interest. The second number is the thread number and is of interest when there are many log statements for discovering whether this log statement is executed in a background thread (or in the same thread as other log statements).

DBI->connect using 'old-style' syntax is deprecated and will be an error in future versions

I've found this error message. What makes it especially interesting, is that in ActivePerl-5.18 I don't get this. I've got this only with the perl-5.14 version in cygwin.
I get this message for the following command:
my $dbh = DBI->connect("dbi:Oracle:$dbname","$login","$password");
What is the exact cause, and the current syntax? Why hasn't ActivePerl-5.18 with this command?
You shouldn't be getting that error from the code that you've posted. That error is triggered when DBI::connect() is given four arguments and the fourth one isn't a reference. The "old-style" connect that the error refers to allowed you to pass the name of the database driver as the fourth argument. This is described in the last paragraph of the documentation for connect().
You wouldn't be getting that error from your code as it only passes three arguments to connect(). Well, unless the parser is getting really confused :-/
Perhaps we need to see more of your code.

How to write appropriate warning messages while writing Gradle plugin?

I am trying to write a Gradle plugin and I have a situation in which user specified bunch of files and when the file is not with specific extension then the warning has to be thrown, because these files can not be processed.
So I am wondering if there is a convention how to construct appropriate warning message, so the message to be clear and not to disappear in the thousands line of project log.
I think something like:
WARNING!!! The file ${file.getName()} is with incompatible extention type ${extention}. The appropriate extension is ${EXTETNIO_TYPE}. The current file will not be taken during the build."
But while looking in the Gradle code. Their warning messages are just the message without WARNING or anything else.
Please, give me your advises.
Warning messages are typically logged with log.warn(). However, if the files cannot be processed, it might be more appropriate to throw a GradleException. Warnings should be avoided whenever possible because they create noise, require the user to always check the command line output, and are easily overlooked.

Why am I getting a buffer overrun error with this line of code?

I only have 1 line of code, and this is:
pcrecpp::RE re("abc");
inside a function OnBnClickedButtonGo(). And this function fails in Release mode, but it works OK in debug mode.
(I am using Visual Studio 8 on Windows XP.)
The error message is:
A buffer overrun has occurred in testregex.exe which has corrupted the program's
internal state. Press Break to debug the program or Continue to terminate
the program.
For more details please see Help topic 'How to debug Buffer Overrun Issues'.
I suspect it is its destructor, which is invisible and implied... but I don't know really.
PS: I am statically linking to the PCRE lib version 7.8.
PS2: Not very relevant, but may help some people who have trouble linking to the PCRE library (it took me hours to sort it out): include the line #define PCRE_STATIC.
I had the same error message in my case. In debug is everything fine, but in release I get the error message. I have a native C/C++ library like native.dll. I have created a mixed unmanaged/managed C++ library, which is a wrapper for that library to .net. Somewhere in this mixed.dll I have an unmanaged function signature declaration, like:
typedef void ( *FunctionOnStartSend)();
for this the I get the message, but if I add a "magic word" there then there is no error message:
typedef void (__stdcall *FunctionOnStartSend)();
If it's happening only in release mode, it's possible that something is getting "optimized" out. Try doing something more than just the one liner, like a Match() and maybe even printing out the matches.
Here is my fresh history:
About a month ago I've got a strange link failure of the VS2008 and that day I dug that setting _SECURE_SCL=0 may help (see link text). And it helped. That day it helped me and I just propagated this setting to all the libs we build at team -- that's because MS says that two libs built with different _SECURE_SCL are incompartible.
Time passed and three days ago I've got a bug when VS2008 says that error message that we see in the first post. And there are no help from the debugger because it overruns only in Release build. I've spend almost 2 days pump'n'jump'n the code of the libs and the overrun was flawed from line to line. Finally I started checking build settings line by line and figured the diff in this setting!
Why, oh why Microsoft guys can't embed some small check in dynamic loader code to test that the library currently running and the one going to be dynamically loaded are incompartible?! Some pice of code that save people's time. Blah!