Edmx file has
<Property Name="SomePrimaryKeyID" Type="bigint" />
Corresponding object's property is
<Property Type="Int64" Name="SomePrimaryKeyID" Nullable="false" />
Query:
long[] ids = new long[]{1234567,1234568};
var results = context.SomeEntities.Where(x=> ids.Contains(x.SomePrimaryKeyID)).ToList();
When I use contains, EF generated query has explicit casting such as
... WHERE SomePrimaryKeyID IN (CAST (1234567 AS BIGINT),CAST (1234568 AS BIGINT))
Since long corresponds to bigint, I don't see a need for cast. Is there a way I can avoid this cast?
For literal integral values the default type in the SQL Server is int. Because of that in your example the literal values would have to be always cast (they would be of type 'int' if there was no explicit cast) to match the type of SomePrimaryKeyID (which is big int). If the explicit case was missing Sql Server would have to do an implicit cast which actually might be more expensive since it would have to first reason about the type of the SomePrimaryKeyID to know what to cast the literal numbers to.
Related
A literal is an object in Scala, so if you store that into a variable such as val x: Int = 5; would this make this an object as well? Everything seems like to be an object in Scala for some reason.
A literal is an object in Scala,
Well. "Literal" is a property of the source code, mostly. As such, the idea of "being an object" doesn't really apply.
What is correct is that every literal evaluates to an object.
So, the literal 1 in a source file is not really an object. It is just part of the source code. But it evaluates to an object, namely an instance of the class scala.Int that represents the mathematical idea of the integer 1.
so if you store that into a variable such as val x: Int = 5; would this make this an object as well?
What do you mean by "this"?
x is not an object, it is a variable. In Scala, like in almost every other language, variables are not objects themselves, rather they are names for objects. (Technically, a variable references an object.)
Int is not an object, either, it is a type. Types aren't objects. It is possible, however, that a type and a term have the same name, and the reason why that works is precisely because types aren't objects and thus there can never be any confusion about whether you are talking about the type or the term.
Now, 5 in this expression is an object, or more precisely, as we have seen above, it is an integer literal with evaluates to an object.
I have a core data model that contains mainly optional attributes. I assumed then that I would not need to unwrap the values that I am assigning to these optional attributes. e.g. I thought I would be able to do:
myEntity.gravity = currentOrder.gravity
(myEntity.gravity being optional)
However, Swift still requires me to unwrap currentOrder.gravity. I would have thought given that the variable I am assigning to is optional that I would not need to unwrap this.
Update:
Here is the definition of one of the core data entities I am describing:
<attribute name="percentComplete" optional="YES" attributeType="Float" defaultValueString="0.0" usesScalarValueType="YES"/>
The entity itself:
<entity name="AircraftMeasurementsCD" representedClassName="AircraftMeasurementsCD" syncable="YES" codeGenerationType="class">
It seems you're equivocating on the word "optional".
The word "optional" in the attribute description optional="YES" is not the same as, and has nothing to do with, the Swift Optional enum type.
The former is merely the ordinary English word "optional", meaning "not required" — for a particular entity, there might or might not be a value for this attribute, which is a Float, but even if there isn't, it's a valid entity. Nothing in the story says that this attribute's type is Optional<Float>. Its type is Float. And you can't assign a Swift Optional where its wrapped type is expected; you have to unwrap it.
Indeed, this point is made very explicitly by the documentation:
Optional attributes aren’t required to have a value when saved to the persistent store. Attributes are optional by default.
Core Data optionals aren’t the same as Swift optionals. [My italics.]
I've seen several ABAP standard methods that return a reference to data as result.
CL_ABAP_EXCEPTIONAL_VALUES=>GET_MAX_VALUE( ) is one of those methods. My natural inclination is to use this method in a single line, like this:
DATA lv_max_value TYPE i.
lv_max_value = CL_ABAP_EXCEPTIONAL_VALUES=>GET_MAX_VALUE( lv_max_value )->*.
Sadly, this doesn't work, because:
Result type of the functional method "GET_MAX_VALUE" is not an object
reference or an interface reference.
The question at hand is: is it possible to dereference such results directly?
Whenever I am certain that results are compatible I would prefer to avoid the old method of dereferencing (storing the reference, assigning it to a field-symbol and then putting it into destination variable) :
DATA lv_max_value TYPE i.
DATA ref TYPE REF TO data.
FIELD-SYMBOLS <field> TYPE any.
ref = CL_ABAP_EXCEPTIONAL_VALUES=>GET_MAX_VALUE( lv_max_value ).
ASSIGN ref->* TO <field>.
lv_max_value = <field>.
It seems like a massive operation for a simple action.
The method GET_MAX_VALUE returns a variable typed TYPE REF TO DATA which is a "reference to a generic data type".
You cannot dereference generic references (*).
However, you can first CAST them, to make ABAP aware of the concrete data type, then dereference the (now typed) result of the cast.
DATA lv_max_value TYPE i.
lv_max_value = CAST i( cl_abap_exceptional_values=>get_max_value( lv_max_value ) )->*.
(*) The documentation of TYPES - REF TO says that only references to complete data types can be dereferenced:
A data reference variable typed in full with TYPE REF TO complete_type or LIKE REF TO dobj can be dereferenced in all matching operand positions using the dereferencing operator ->*. If the static data type is structured, the object component selector enables access to the components of the structure with dref->comp.
and this documentation explains that a complete data type is a "Data type that is not generic."
I have a lot of enumerations as properties in my codefluent model. Codefluent uses an int as datatype to store this. In all cases a TinyInt would suffice. I can set the datatype to int16. How can i reduce it even further to set it to TinyInt.
PS Maybe setting it to INT16 by default would be better for enums.
The attribute enumTypeName allows to define the underlying CLR full type name. The DbType is inferred from the CLR type name. If you set System.Int16, the DbType will also be Int16:
<cf:enumeration name="Gender" enumTypeName="System.Int16">
<cf:enumerationValue name="Unspecified" />
<cf:enumerationValue name="Male" />
<cf:enumerationValue name="Female" />
</cf:enumeration>
You can set the value of this attribute in the graphical interface:
Read carefully before you answer! I want to cast an integer to an enum type where the integer value is not actually defined in the enum. In VB.Net, it is possible to directly cast any integer to an integer-based enum type using DirectCast. Is there some way to accomplish this natively in PowerShell?
I need to do this in PowerShell in order to call a method on an Office Interop object (Access.Application.SysCmd) which takes an enumeration value as its first argument (AcSysCmdAction), but where the actual value I need to pass (603 for the undocumented export to accde action) is not included in the PIA enum definition. PowerShell's built-in type conversion cause it to convert either a number or a string the applicable enumeration type, but it will not coerce an int value that is not in the enum. Instead it throws an invalid conversion exception. Right now I'm resorting to a dynamically compiled ScriptControl which calls SysCmd via VBScript, but I'd like to keep everything in PowerShell if possible.
You could call the Enum class's ToObject method:
$day = [Enum]::ToObject([DayOfWeek], 90)
Well, I just figured out a way. In PowerShell, it appears enum objects have a property called "value__" which can be directly set to any value!
#Create a variable with the desired enum type
$ops = [System.Text.RegularExpressions.RegexOptions]0
#Directly set the value__ property
$ops.value__ = 3450432