Has Yesod setMessage function a size limit? - haskell

I'm using Yesod and I'm experiencing a strange bug.
I'm uploading csv file and when the format is incorrect I display as a message (using setMessage) the uploaded file with some error message. When the file is too big, I don't get any message at all, as if I didn't set the message (or the message has been discarded).
I'm pretty sure the problem is on my side, but ss it possible that setMessage a size limit and discart too big message ? I guess setMessage uses session or something and it might have some restrictions .

Related

Insert data into database using sqlldr in coldfusion

I have a CSV file that I got from a website. I need to upload that same CSV file into my database using SQLLDR in ColdFusion. For some reason I'm not able to insert the data into database.
Below is my code. Using this code I was not able to insert the data into database from the CSV file. It is working file from a batch file, but it is not working using cfexecute. By that I mean, I'm getting a blank screen. No errors, no exceptions, nothing. Checked in the logs but I did not get any errors there either. Only thing what I can see is that the data is not inserted into the database.
FYI, we are using Linux environment, so the path is slightly different.
<cfset CTLPATH="/home/mosuser/apps/nodal/ctl">
<cfset LOGPATH="/home/mosuser/apps/nodal/logs">
<cfexecute name="/opt/oracle/product/12.1.0/client_1/bin/sqlldr"
arguments="userid/password#Sid control=#CTLPATH#/mpimReport.ctl
log=#LOGPATH#/#PathfileName#_load.log data=#filelist##PathfileName#.csv
bad=#LOGPATH#/#PathfileName#_error.txt">
</cfexecute>
Update:
As suggested, dumping the error variable qryerr showed:
Message 2100 not found; No message file for product=RDBMS,
facility=ULMessage 2100 not found; No message file for product=RDBMS,
facility=UL
Add a few parameters to your <cfexecute> call.
timeout - in the order of the number of seconds expect the process to take
variable - the name of the variable to hold the STDOUT output of sqlldr
errorVariable - name of the variable to hold the STDERR output of sqlldr
After doing that you can get the output of the call and inspect it for any error messages and other info.
Adding the timeout is the crucial step - this makes cfexecute block until either the program terminates or the timeout is reached. Without a timeout, ColdFusion simply kicks off the process and immediately continues executing the rest of the current page.

Displaying device payload in node red

I ma new to Node-red and still finding my way around it. I am using SmartMesh network motes that communicate with a manager connected to my laptop.
How can I just display in the debug window the whole payload that is coming through in JSON format? Do I just use a debug node with msg.payload or I need to use a function node?
An help is very much appreciated!
Assuming the data you want is contained in the msg.payload field then a normal debug node should be fine.
If the data is else where in the msg object then you can change the debug node to show the whole message.
But be aware there is a limit to how much data will be shown in the debug sidebar in order to stop the debug node having too greater impact on performance. If the payload it too large it will be truncated. You can still see the whole output by changing the debug node to print to the console as well as the debug sidebar.
You can also change the limit (debugMaxLength) in the settings.js if you want to, but it is better to leave that value at it's default.

"$ ./propellor --list-fields" yields "propellor: Prelude.read: no parse"

I am trying to specify a private field using Haskell's Propellor deployment library.
As context: the field in question is a file whose content I want to encrypt and have propellor place on the destination server during deployment. However, I haven't gotten nearly that far; before even attempting to set the field, I have run into an error while attempting to simply view propellor's current private fields.
Specifically, when I run the command to view fields, $ ./propellor --list-fields, it asks for my gpg key, prints some gpg key information, and then the following:
Currently set data:
Field Context Used by
----- ------- -------
propellor: Prelude.read: no parse
There should be some fields present which were set previously, but somehow they are not displayed here and instead I get only the propellor: Prelude.read: no parse error message. I have not yet attempted to add my own field.
It seems that propellor is having an issue trying to parse something, but I do not know what that could be. I realize this is not a lot to go on but am not sure what else to do. Has anyone run into a similar error with Haskell's propellor before or know what the issue could be?
Your self-answer is correct; here I will just look at the issue in a different light.
The error you got points to the read function in Prelude. read is an example of a partial function: its type...
read :: Read a => String -> a
... says that it can convert Strings into a value of any type a with a Read instance; however, we known that this does not work for all Strings, as the parsing might fail. To put it more dramatically, the type of read is a lie.
It is generally a good idea to avoid partial functions, not only because more often than not they are bugs waiting to happen (e.g. you assume the parse will never fail due to some precondition in your business logic, and then the precondition changes), but also because they tend to give extremely uninformative error messages (as you just noticed). In the case of read, for instance, a nicer alternative is readMaybe, which returns Nothing if the parsing fails. That gives an opportunity to react to the failure. In dfferent situations you might, for instance, find it appropriate to ask the user to retry, supply a default value or, if there is no other recourse, terminate the program with an error message that explains what went wrong in terms of what you are trying to do.
Sorry this question was so vague, but there was very little to go on from the error message. The issue is now resolved and here is an explanation in case it is helpful to anyone who comes across it while facing a similar error.
The code contained an instance of a configuration data type defined not in a module, but in a text file being read in via the Read class. In short, the issue was that I had altered the data type without comprehensively updating the text-defined configuration instance to accomodate the type change.
In the long-form version of the explanation the issue is sneakier, involving merging the data type change over a change to the text-configuration which was not recognized as in conflict due to no line conflicts.
But essentially the error was failure to read in a data type instance defined in text-form.
I have plans to define the configuration data instance in a module rather than reading it in from text, which should be caught by the compiler and give a more meaningful error message should a similar error arise.

Setting maximum upload size with deform.widget.FileUploadWidget

How one can limit maximum upload size with deform.widget.FileUploadWidget() so that the validation fails with a friendly error message if the file is too large?
Maybe this code from Kotti can help. The answer seems to be a custom validator.

What is the standard way to handle users opening incorrect file types?

I hope my Q was clear ... I am curious about the typical way to code for someone clicking File|Open, and selecting a file that is inappropriate for the program--like someone using a word processing program and trying to open a binary file.
In my case, my files have multiple streams streamed together. I'm unsure how to have the code validate whether an improper file was selected before the app throws a stream read exception. (Or is the way to handle the situation to just write code to catch a stream read exception?)
Thanks, as always.
I think it's quite usual that you have code that just tries to open the file, and if it fails, an error is shown to the user. Most file formats has some kind of header with a "magic number", so that the reader can tell if it's not the right file very quickly after reading the first few bytes of the file.
Magic number at the start of the file generally helps -- if you have control of the file format.
Otherwise, yeah -- catch the exception and put up a dialog.

Resources