I have a huge query string which is around 6000 to 7000 characters, is it possible to encrpyt the string in short?
any alogrithms ?
Usign ASP.NET as the web app.
The short answer is don't do it - it probably indicates you are doing something wrong.
If you have to then I would say the best way would be to store the long query string in a database field and generate a Guid you can store as a key against it.
You can then pass the Guid in the query string and when the page loads you can then retrieve the full details from the database using the key.
The URL accepts 255 character, after that you'll get nothing.
Use what Mr. Kevin mentioned, database storage, or use the context session to store variables you are sending in the query string.
Related
Actual variable is Long but while saving it to Firestore I accidentally converted it to String, now I cannot perform queries like whereGreaterThan, whereLessThan, orderBy etc on this String field
There isn't a way to magically change the data type. The easiest way will be to re-write all the documents that were saved as a string.
You could use something like the Python server libraries to do this, using Cloud Shell in the GCP Console.
Note, you can grab all the documents with the field set to a string by doing a filter for >= "". This will get you every field that has a string with any value, as well as empty strings.
Is it possible to search Vertex properties with a contains in Azure Cosmos Graph DB?
For example, I would like to find all persons which have 'Jr' in their name?
g.V().hasLabel('person').has('name',within('Jr')).values('name')
Seems like the within('') function only filters values that are exactly equal to 'Jr'. I am looking for a contains. Ideally case insensitive.
None of the text matching functions are available for CosmosDB at this time. However, I was able to implement a wildcard search functionality by using a UDF (User Defined Function) which uses the Javascript match() function:
function userDefinedFunction(input, pattern) { return input.match(pattern) !== null; };
Then you'd have to write your query as SQL and use the UDF that you defined (the example below assumes you called you function 'REGEX'
SELECT * FROM c where(udf.REGEX(c.name[0]._value, '.*Jr.*') and c.label='person')
The performance will be far from ideal so you need to decide if the solution is acceptable or not based on your latency and cost perspectives.
The Azure team has now implemented Tinkerpop predicates for String
The Azure team has "announced" this to a user here on their feedback website.
I haven't tested all of them, but containing works for me (it is case sensitive though)
g.V().hasLabel('doc').or(__.has('title', containing('truc')), __.has('tags', containing('truc')))
TextP.startingWith(string)
Does the incoming String start with the provided String?
TextP.endingWith(string)
Does the incoming String end with the provided String?
TextP.containing(string)
Does the incoming String contain the provided String?
TextP.notStartingWith(string)
Does the incoming String not start with the provided String?
TextP.notEndingWith(string)
Does the incoming String not end with the provided String?
TextP.notContaining(string)
Does the incoming String not contain the provided String?
I am using ASP.NET identity in MVC 5 and wondered the best way to perform string comparison during say, a query to a table where records have been entered with the userId as an foreign key.
Normally I would just plump for == but I wasn't sure how the string for a userId inside .NET identity is created.
I guess it's actually a GUID of sorts under the hood so I'd presume that == would be fine but I wondered if the culture or case would come into it at all.
Does anyone know if the string is a unique GUID for == type comparison, or should I be using string.Equals and some StringComparison option to account for cultures?
ASP.NET Identity can use GUID for keys. In that case GUID should not have any culture specific characters. So StringComparision. InvariantCultureIgnoreCase should go for string.Equals in C#. ToLower (ToUpper) can be used for SQL queries (LINQ).
You probably want to use Ordinal/OrdinalIgnoreCase StringComparisons here as it compares strings character by character without regard to linguistic convention.
Read more here: https://msdn.microsoft.com/en-us/library/cc165449.aspx
And here: https://msdn.microsoft.com/en-us/library/system.stringcomparison(v=vs.110).aspx
Code samples:
string1.Equals(string2, StringComparison.Ordinal);
string1.Equals(string2, StringComparison.OrdinalIgnoreCase);
I'm trying to understand why the new ASP.NET Identity tables stopped using Guid (uniqueidentifier type) as keys - instead it is now using nvarchar(128) but still keep a Guid as a string...
Isn't it a huge waste? (uniqueidentifier is just 2 integers vs the whole Guid as a 36 character string)
I'm suspecting that Entity Framework might be responsible for this...
Is it safe to change back to uniqueidentifier keys?
Can anyone tell me what are the benefits of using 36 character strings?
Identity is built to work on multiple storage platforms and not every storage platform has Guid as a supported storage type.
You can change the default string pkey into Guid, but that involves some work on your C# models. Or you can change the pkey into an int - whatever you like. Just be aware that there is a huge debate about which is better.
I'm using this code to store korean string in my database:
Dim username As String = Request.QueryString.Get("Some Korean String")
Using dg As New DataContext()
Dim newfriend As New FriendsTable With {.AskingUser = User.Identity.Name, .BeingAskedUser = username, .Pending = True}
dg.FriendsTables.InsertOnSubmit(newfriend)
dg.SubmitChanges()
end using
Checking my database, the username stored is a string"????"...
anybody got an idea how this happened or any workarounds?
What is your database collation? Are you able to store Korean strings with any other data access technology? What is the type of the username column, and is it accurately mapped in LINQ to SQL?
I suspect that something in the database isn't set up correctly to allow full Unicode. I very much doubt that this has anything to do with LINQ itself.
The other thing to check is that you're actually getting the right data in the first place. There are often several places where things can go wrong - you need to validate each place separately to see where the data is being corrupted. I have a short article on this which you may find helpful.
It sounds like you are storing Korean text in a varchar/text column which is not using a Korean collation. Thea easiest fix is to change the column type to nvarchar/ntext.
The nchar column types store Unicode data, whereas the char and varchar types store single byte characters in the specified collation.