Does Mule platform supports the "-" (hyphen) in payload keys when accessing them? If it does support can anyone provide an example or sample source for the same? I have a payload key with that special character and Mule fails to reference it directly.
You cannot reference keys with special values directly as those special values may be reserved characters or functions. What you should do is reference them in between '.
In the example you mentioned, instead of referencing the "sample-data" as #[payload.sample-data.test] you should reference it as #[payload.'sample-data'.test]
Related
I am trying to add a label to my bigquery table/view using the following bq command.
bq update --set_label primary_keys:a,b project-id:dataset.tablename
The command works perfectly fine if I have only one key (a) as the primary key. However, when I try to insert multiple keys (a,b) separated by comma then it throws an invalid characters error. Is there a way to add multiple keys within the same label separated by comma.
I don't think that this is feasible, thus comma character is not accepted there, according to the documentation:
Keys and values can contain only lowercase letters, numeric
characters, underscores, and dashes. All characters must use UTF-8
encoding, and international characters are allowed.
According to the documentation, labels are key-value pairs that helps you organize your Google Cloud BigQuery resources.
Being a key-value pair is a requirement as per the documentation, and this is not compatible with your intention of giving two different values to the same key.
I try to create a phonebook with OpenLDAP 2.4.31 with the standard schemas.
Inserting a number containing a hash (#) or asterisk (*) won't work and return me a syntax error.
RFCs tell me that a number is the following: Printable string (alphabetic, digits, ', (, ), +, ,, -, ., /, :, ?, and space) and "
How can I edit the schema to support # and * characters?
We are having the same exact issue! Mobile networks offer a variety of services and information accessed using numbers that include either pound (hash) or star. Its a perfectly valid question for perfectly normal use of a phone number field.
Having a very casual look at RFC 4517, I see that it's really true! The LDAP RFC offers only a very limited selection of basic syntax types, and telephoneNumber maps to PrintableString. Probably a case of the RFCWG more interested in their RFC for its own sake, than the practical application thereof. I mean, which would be more useful in a phone number field - '?' or '#'..
As was already alluded, hacking cosine.schema can lead to even larger problems and is not upgrade-safe. FYI there are a few LDAP servers out there, many a bit more flexible about the RFC implementation. Have a look at OpenDJ:
https://forgerock.org/opendj/
Any server-side 'fix' in this case will likely no longer be strictly RFC compliant, which runs the risk of your original syntax issues revisiting you, if you ever need to exchange LDIF with other LDAP systems. But IMHO changing the client mapping to another unrelated field type could hardly be called 'better', especially from an onlooker's perspective. So either get another LDAP server which is more forgiving or change the field mapping on the client - either way presents risks and should be understood as a limitation of RFC 4517.
You would have to change the OID in the telephoneNumber schema entry to refer to a more general attribute syntax OID as per the RFCs. Not a good idea. You would be better off using a different attribute.
I have to pass data to BAdI acc_document in parameter extension1 of BAPI bapi_acc_document_post, but i don't know how to do that using SAP .Net connector.
Any suggestions?
Regards, Devinder
BAPI extension parameters are pretty much free-form - as you can see, for BAPI_ACC_DOCUMENT_POST parameters EXTENSION1 and EXTENSION2 are defined as tables with character fields.
You can store whatever data you want to into them and use them as you do any other BAPI parameters, the key is that you need to interpret the values in your enhancement. For example, if the caller stores an external document number into a row of EXTENSION1, just interpret it as a document number when you use it in your BADI. If you're passing a structure in the extension parameter it can be a little trickier (as you have multiple fields to deal with), but the same principle applies.
From the documentation on properly passing SQL parameters to psycopg2:
"Only variable values should be bound via this method: it shouldn’t be used to set table or field names. For these elements, ordinary string formatting should be used before running execute()."
http://initd.org/psycopg/docs/usage.html#passing-parameters-to-sql-queries
Why is this? Why would setting a field name not have the same SQL injection problems as setting values?
Because you don't usually receive names of your tables or fields from users, you specify them in your code yourself. If you generate your request based on values got from user input, than yes, you should do some kind of escaping to avoid SQL injections.
I have the following code to create an object type in Oracle (PL??)
CREATE OR REPLACE TYPE STAFF_T as OBJECT(Staff_ID# NUMBER, Person PERSON_T); \
I'd like to know what is the significance of the # appended to the Staff_ID variable in the declaration?
No special meaning.
Oracle allows using $, _ and # in identifiers, just like any other alphanumeric characters, but the identifier should begin with an alpha character (a letter).
That's part of the column name Staff_ID#. The pound sign is an allowable part of an identifier (table/column name) in PL/SQL. See here
Whoever wrote the code probably didn't mean anything special by #.
But # apparently means something to Oracle, although I don't know what. From the SQL Language Reference:
Oracle strongly discourages you from
using $ and # in nonquoted
identifiers.
Here are some guesses for what the warning is about:
it's related to a really old bug (the
warning goes back to at least Oracle
7)
Oracle plans to do something with
it in a future verison
that character
isn't available on all keyboards, character sets, or platforms that Oracle supports
The data dictionary uses the number sign a lot, and as far as I can tell it works just fine for user objects. But just to be safe you might want to remove it.