I've opened a bug on Microsoft Connect for this, but no response (see edit below for their response) in a long while. So here it goes:
When trying to request an entity framework with its relation using the "Include" function in the linq query, it's impossible to request a relation through a path of more than 8 steps (8 . dot characters in the path). This prevents me from completing some of my dynmically generated queries that require access to more than that level of redirection.
Instead of completing the query successfully I get the following exception:
"Foo.Bar.Baz...(some more path string here)", the current limit of "8" is insufficient.
at System.Data.Common.MultipartIdentifier.IncrementStringCount(String name, String[] ary, Int32& position, String property)
at System.Data.Common.MultipartIdentifier.ParseMultipartIdentifier(String name, String leftQuote, String rightQuote, Char separator, Int32 limit, Boolean removequotes, String property, Boolean ThrowOnEmptyMultipartName)
at System.Data.Objects.Span.ParsePath(String path)
at System.Data.Objects.Span.Include(String path)
at System.Data.Objects.Span.IncludeIn(Span spanToIncludeIn, String pathToInclude)
Has anyone figured why this is so, or a way around this? Looking at the code (with Reflector) of ParsePath it seems that they hard-coded the magic number 8 in there...
UPDATE: Microsoft's response:
Thank you for raising this issue. We plan to remove the limit of the number of elements in an Include path in the next release.
UPDATE 2: Despite Microsoft's response quoted above, the bug was not fixed in EF 4.1
UPDATE 3: According to Microsoft, should be fixed in .NET 4.5, but I didn't test the developer preview to see if it works.
probably fixed in latest .net 4.5
https://connect.microsoft.com/VisualStudio/feedback/details/640423/entity-framework-include-strings-are-arbitrarily-limited-to-a-path-of-depth-8#tabs
I have not seen this, but here are 2 possible work arounds:
Loop through the data and use Load for each row. Note this will create a call to the database for each row, so it is really slow.
Flatten the data in a view and then select from the view. This creates a lot of redundant data, so more memory and network use.
Related
and thanks for looking!
I have an instance of YouTrack with several custom fields, some of which are String-type. I'm implementing a module to create a new issue via the YouTrack REST API's PUT request, and then updating its fields with user-submitted values by applying commands. This works great---most of the time.
I know that I can apply multiple commands to an issue at the same time by concatenating them into the query string, like so:
Type Bug Priority Critical add Fix versions 5.1 tag regression
will result in
Type: Bug
Priority: Critical
Fix versions: 5.1
in their respective fields (as well as adding the regression tag). But, if I try to do the same thing with multiple String-type custom fields, then:
Foo something Example Something else Bar P0001
results in
Foo: something Example Something else Bar P0001
Example:
Bar:
The command only applies to the first field, and the rest of the query string is treated like its String value. I can apply the command individually for each field, but is there an easier way to combine these requests?
Thanks again!
This is an expected result because all string after foo is considered a value of this field, and spaces are also valid symbols for string custom fields.
If you try to apply this command via command window in the UI, you will actually see the same result.
Such a good question.
I encountered the same issue and have spent an unhealthy amount of time in frustration.
Using the command window from the YouTrack UI I noticed it leaves trailing quotations and I was unable to find anything in the documentation which discussed finalizing or identifying the end of a string value. I was also unable to find any mention of setting string field values in the command reference, grammer documentation or examples.
For my solution I am using Python with the requests and urllib modules. - Though I expect you could turn the solution to any language.
The rest API will accept explicit strings in the POST
import requests
import urllib
from collections import OrderedDict
URL = 'http://youtrack.your.address:8000/rest/issue/{issue}/execute?'.format(issue='TEST-1234')
params = OrderedDict({
'State': 'New',
'Priority': 'Critical',
'String Field': '"Message to submit"',
'Other Details': '"Fold the toilet paper to a point when you are finished."'
})
str_cmd = ' '.join(' '.join([k, v]) for k, v in params.items())
command_url = URL + urllib.urlencode({'command':str_cmd})
result = requests.post(command_url)
# The command result:
# http://youtrack.your.address:8000/rest/issue/TEST-1234/execute?command=Priority+Critical+State+New+String+Field+%22Message+to+submit%22+Other+Details+%22Fold+the+toilet+paper+to+a+point+when+you+are+finished.%22
I'm sad to see this one go unanswered for so long. - Hope this helps!
edit:
After continuing my work, I have concluded that sending all the field
updates as a single POST is marginally better for the YouTrack
server, but requires more effort than it's worth to:
1) know all fields in the Issues which are string values
2) pre-process all the string values into string literals
3) If you were to send all your field updates as a single request and just one of them was missing, failed to set, or was an unexpected value, then the entire request will fail and you potentially lose all the other information.
I wish the YouTrack documentation had some mention or discussion of
these considerations.
I am using EF 6.1.3. Using code first sets a byte[] property in an entity to max. 8000 bytes. Any attempt to make it greater, that is MAX, fails.
HasMaxLength(null) (yes, the parameter is int?) still sets it to 8000, HasMaxLength(int.MaxValue) or any other value greater than 8000 makes EF throw System.Data.Entity.Core.MetadataException:
Schema specified is not valid. Errors: (0,0) : error 0026: MaxLength
'2147483647' is not valid. Length must be between '1' and '8000' for
'varbinary' type.
SQL server 13.0.2151 (mssqllocaldb) allows for varbinary(max):
This limit seems too severe to me. Trying to find a reason why it is imposed does not yield a good reason for this too. So, my question is
How a byte[] can be mapped to varbinary(max) in EF code first?
PS: The property is also 'required', but I am not sure if an optional property may be set to varbinary(MAX) either. Anyway, i have not tested this case since it does not make much sense to me.
Despite the multiple articles that states the solution is to add the following attribute
[Column(TypeName="image")]
byte[] Photo { get; set; }
I found the correct approach to be, adding instead this attribute
[MaxLength]
public byte[] Photo { get; set; }
With the Column(TypeName) recommendation I'll end up getting the following error with SQLCE:
The field Photo must be a string or array type with a maximum length of '4000'
Well, I found a workaround to this. Specifying HasColumnType("image") solves the problem, but I still think that EF must allow for specifying varbinary(max) as well.
Moreover, not all binary files are images. ;)
And still part of the question remains unanswered, so I will put it this way:
Why a byte[] property cannot be mapped to varbinary(max) in EF code first?
Any comments (or answers of course) are welcome. Thanks in advance.
EDIT (as per comment by Gert): leaving the property without any specs makes EF generate varbinary(max). Surprisingly simple!
It is possible.
Fluent API
.IsMaxLength()
Before you want to update the database take a look in the filename which is generated after you use "add-migration filename"
If you see a method "CreateTable" and see that a field which should te be a binary type with a lenght of MAX, it can be generated as c.Binary(maxLength: 8000), remove the parameter maxLength at all and then use update-database and after that you can check the created table in the SQL server database!
I'm trying to produce a query that will return all pages under a path where a property is NOT present.
Effectively I want the query builder query that will produce the following xpath: /jcr:root/content/site/my/path//element(*, cq:Page)[not(jcr:content/task/#finished)]
For CQ 5.3 the 'exists' property doesn't seem to be present (according to the docs: http://docs.adobe.com/docs/en/cq/5-3/javadoc/com/day/cq/search/eval/JcrPropertyPredicateEvaluator.html), however it looks like I can use 'not', so I've tried the following two examples but neither work as I expect in query debugger:
1
path=/content/site/my/path
type=cq:Page
property=jcr:content/task/finished
property.operation=not
2
path=/content/site/my/path
type=cq:Page
property=jcr:content/task/finished
property.operation=not
property.value=true
I've also seen pages that suggest these should work, and I can't seem to see any hotfixes that would cover fixing this (assuming it isn't actually working correctly).
Can anyone offer a solution or point out where I'm going wrong?
Using CQ 5.3, upgraded to crx 2.2.
Cheers
Chris
I have a few resource that I hope help you:
My blog post about query API options: http://itgumby.github.io/blog/2014/10/cq-queries-demystified/
6 Dimension's post about specific query examples: http://labs.sixdimensions.com/blog/2014-10-07/9-jcr-sql-2-queries-every-aem-dev-should-know/
Adobe QueryBuilder documentation: http://docs.adobe.com/docs/en/aem/6-0/develop/search/querybuilder-api.html
Non-empty SQL2 (From the 6D post):
SELECT * FROM [cq:PageContent] WHERE [jcr:title] IS NOT NULL
Which means you could convert that to WHERE [jcr:title] IS NULL
If using QueryBuilder predicates, the property generally won't exist (deleted from node) if it is false. Please manually verify in your case using CRX-DE lite and examining the node & its properties. If the property does exist, but its value is false, then:
path=/content/site/my/path
type=cq:Page
property=#jcr:content/task/finished
property.value=false
For any still struggling, this is how you do it
path=/content/site/my/path
type=cq:Page
property=jcr:content/task/finished
property.operation=exists
property.value=false
I am trying to send a search input to a REST service. In some cases the form input is a long string of numbers (example: 1234567890000000000123456789). I am getting 500 error, and it looks like something is trying the convert the string to a number. The data type for the source database is a string.
Is there something that can be done in building the query string that will force the input to be interpreted as a string?
The service is an implementation of ArcGIS server.
More information on this issue per request.
To test, I have been using a client form provided with the service installation (see illustration below).
I have attempted to add single and double quotes, plus wildcard characters in the form entry. The form submission does not error, but no results are found. If I shorten the number("1234"), or add some alpha numeric characters ("1234A"), the form submission does not error.
The problem surfaced after a recent upgrade to 10.1. I have looked for information that would tie this to a known problem, but not found anything yet.
In terms of forcing the input to be interpreted as a string, you enclose the input in single quotes (e.g., '1234567890000000000123456789'). Though if you are querying a field of type string then you need to enclose all search strings in single quotes, and in that case none of your queries should be working. So it's a little hard to tell from the information you've provided what exactly you are doing and what might be going wrong. Can you provide more detail and/or code? Are you formatting a where clause that you are using in a Query object via one of Esri's client side API's (such as the JavaScript API)? In that case, for fields of data type string you definitely need to enclose the search text in single quotes. For example if the field you are querying were called 'FIELD', this is how you'd format the where clause:
FIELD = '1234'
or
FIELD Like '1234%'
for a wildcard search. If you are trying to enter query criteria directly into the Query form of a published ArcGIS Server service/layer, then there too you need to enclose the search in single quotes, as in the above examples.
According to an Esri help technician, this is known bug.
I am using code similar to this Support / KB article to return multiple recordsets to my C# program.
But I don't want C# code to be dependant on the physical sequence of the recordsets returned, in order to do it's job.
So my question is, "Is there a way to determine which set of records from a multiplerecordset resultset am I currently processing?"
I know I could probably decipher this indirectly by looking for a unique column name or something per resultset, but I think/hope there is a better way.
P.S. I am using Visual Studio 2008 Pro & SQL Server 2008 Express Edition.
No, because the SqlDataReader is forward only. As far as I know, the best you can do is open the reader with KeyInfo and inspect the schema data table created with the reader's GetSchemaTable method (or just inspect the fields, which is easier, but less reliable).
I spent a couple of days on this. I ended up just living with the physical order dependency. I heavily commented both the code method and the stored procedure with !!!IMPORTANT!!!, and included an #If...#End If to output the result sets when needed to validate the stored procedure output.
The following code snippet may help you.
Helpful Code
Dim fContainsNextResult As Boolean
Dim oReader As DbDataReader = Nothing
oReader = Me.SelectCommand.ExecuteReader(CommandBehavior.CloseConnection Or CommandBehavior.KeyInfo)
#If DEBUG_ignore Then
'load method of data table internally advances to the next result set
'therefore, must check to see if reader is closed instead of calling next result
Do
Dim oTable As New DataTable("Table")
oTable.Load(oReader)
oTable.WriteXml("C:\" + Environment.TickCount.ToString + ".xml")
oTable.Dispose()
Loop While oReader.IsClosed = False
'must re-open the connection
Me.SelectCommand.Connection.Open()
'reload data reader
oReader = Me.SelectCommand.ExecuteReader(CommandBehavior.CloseConnection Or CommandBehavior.KeyInfo)
#End If
Do
Dim oSchemaTable As DataTable = oReader.GetSchemaTable
'!!!IMPORTANT!!! PopulateTable expects the result sets in a specific order
' Therefore, if you suddenly start getting exceptions that only a novice would make
' the stored procedure has been changed!
PopulateTable(oReader, oDatabaseTable, _includeHiddenFields)
fContainsNextResult = oReader.NextResult
Loop While fContainsNextResult
Because you're explicitly stating in which order to execute the SQL statements the results will appear in that same order. In any case if you want to programmatically determine which recordset you're processing you still have to identify some columns in the result.