Return Default Result For in Value Regardless

Return default result for IN value regardless

You have a condition on OnlineUseage the left join become like a inner join.

move your condition to the from clause will be better :

SELECT
    users.Name,
    users.ID,
    IFNULL(SUM(users.Minutes), 0) AS MinutesOnline
FROM
    users
    LEFT JOIN OnlineUseage ON
        OnlineUseage.ID = users.ID and
        OnlineUseage.Date >= '2016-01-01 00:00:00' AND
        OnlineUseage.Date <= '2016-12-31 23:59:59'
WHERE
    users.ID IN (332,554,5764,11,556,.........)
GROUP BY
    users.ID,users.Name
ORDER BY
    users.ID

default(T?) does not return null when T is a value type

In the absence of a where T : struct constraint, T? does not mean Nullable<T>; it means "T, but note that it won't be null in the NRT sense" - and since NRT nulls never apply to your value-type scenario: it basically just means T; and the default value of a value-type T is not null (in any sense).

In the scenario where you need "null checking" that crosses both value-type and reference-type scenarios including support for value-types without a value, then the easiest approach is usually to forget about Nullable<T> and just track:

1. do I have a value (bool), and
2. what is the value (T)

separately, and explicitly; this could be via any of:

• bool SomeMethod(out var T)
• (HasValue: bool, Value: T) SomeMethod()
• Maybe<T> SomeMethod()

(where Maybe<T> is just a custom struct that is composed of a bool HasValue and a T Value)

This is effectively creating something akin to Nullable<T>, but which applies to all values, regardless of type. Instead of checking for null, just check .HasValue first, and if true, assume that the value is meaningful.

Returning Default Value from List when match is not found

You could use DefaultIfEmpty() of LINQ:

var res = list.Where(x => x.Age == 61)
              .Select(t => t)
              .DefaultIfEmpty(list.First(x => x.Threshold == list.Max(t => t.Threshold)))
              .SingleOrDefault();

GetValueT always getting null/default regardless of type

I'm going to assume you are passing test:SomeValue as your key and you configuration looks like:

"test": {
    "SomePath": "Some value",
    "AlsoTried": 13,
    "AndEven": true
}

Your call to self.GetSection(key); is returning the specific value you have asked for e.g.

var section = self.GetSection("test:SomePath");

This means section is now the "value" of that path e.g. Some value, which is why the section.Value property returns the correct data. But when you call section.GetValue<string>("test:SomePath") or just section.GetValue<string>("SomePath") then section does not contain a KeyValuePair for "SomePath", so you get null.

If you call GetValue<string>(key) on self it will return the correct value:

var section = self.GetValue<string>(key);

type operator return value for null

According to MDN this is a bug in ECMAScript, should be null.

In the first implementation of JavaScript, JavaScript values were
represented as a type tag and a value. The type tag for objects was 0.
null was represented as the NULL pointer (0x00 in most platforms).
Consequently, null had 0 as type tag, hence the bogus typeof return
value. (

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof

SQL Sever stored procedure keeps returning value of 1

In SQL Server, stored procedures return a success value which is an integer. I'm not sure what the stored procedure does when given a money type.

However, you should be executing it as:

declare @print money;

exec spConvert @date='2017-05-25', @convertFrom='euro', @convertTo='dollar', @value=@print output ;

print @print;

You should also adjust the stored procedure so it doesn't return anything or returns a status value.

EDIT:

I should also note that your stored procedure only consists of one statement. Use BEGIN and END:

CREATE PROC spConvert (               
    @date date,
    @convertFrom varchar(20),
    @convertTo varchar(20),
    @value money output
) AS 
BEGIN
    SELECT @value = value 
    FROM Conversion c JOIN
         Currency c1
         ON c.ToID = c1.currencyID JOIN
         Currency c2 
         ON c.FROMID = c2.currencyID 
     WHERE c1.name = @convertTo AND c2.name  =@convertFrom AND
           @date BETWEEN StartDate AND EndDate                    

    IF @value is null  -- This seems dangerous, because @value is not initialized in the stored procedure
    BEGIN  
        SELECT @value = Value 
        FROM Conversion c JOIN
             Currency c1
             ON c.ToID = c1.currencyID JOIN
             Currency c2
             ON c.FromID = c2.currencyID 
         WHERE c1.name = @convertTo AND c2.name = @convertFrom AND
               Enddate is null           
         )
    print @value;  -- I don't know what this is for
END;

Problem using a class that always returns 0 regardless of the value

private double real;
private double imaginario;
public Complejos(double Real, double Imaginario)
{
    real = Real; // <= this sets the private var "real" to the value of the _param_ "Real".
    imaginario = Imaginario;
}


public double Real { get; set; } // <= This is an autoproperty that has 
                                 //    NOTHING TO DO with "real"
                                 //    and is initialized with default(double), which is 0.0
public double Imaginario { get; set; }

So, since field real and property Real are not related in any way, you will get the default value of a double-property when you read-access Real like in your example.

Two ways of fixing this:

1. Using a field-backed property instead of auto

     public double Real {
          get { return real; }
          set { real = value;}
     }

2. Using the autoproperty in the CTOR and dropping the private field.

public Complejos(double Real, double Imaginario)
    {
        this.Real = Real; // <= this sets the property "Real" to the value of the _param_ "Real".
        this.Imaginario = Imaginario;
    }

I'd chose option 1. only if I had a very good reason to do so. Basically, the AutoProperty will create a private field "under the hood" anyway.

Empty return in func with return value in golang

The function uses a "named" return value.

From the spec on return statements:

The expression list may be empty if the function's result type
specifies names for its result parameters. The result parameters act
as ordinary local variables and the function may assign values to them
as necessary. The "return" statement returns the values of these
variables.

Regardless of how they are declared, all the result values are
initialized to the zero values for their type upon entry to the
function. A "return" statement that specifies results sets the result
parameters before any deferred functions are executed.

Using named returns allows you to save some code on manually allocating local variables, and can sometimes clean up messy if/else statements or long lists of return values.

func a()(x []string, err error){
    return
}

is really just shorthand for

func a() ([]string,error){
  var x []string
  var err error
  return x,err
}

Its a bit shorter, and I agree that it may be less obvious.

Named returns are sometimes needed, as it allows things like accessing them inside a deferred function, but the naked return is just syntactic sugar as far as I can tell, and is never strictly required.

One place I see it commonly is in error return cases in functions that have many return values.

if(err != nil){
   return
}
return a,b,c,nil

is easier than

if(err != nil){
   return nil,nil,nil,err
}
return a,b,c,nil

when you have to write it a bunch of times. And you don't have to modify those returns if you change the signature to have additional "real" return values.

Most places I am using them in the codebase I just searched, they definitely seem to be hiding other smells, like overly complex multi-purpose functions, too deep if/else nesting and stuff like that.

SQL LEFT JOIN with WHERE statement after is not displaying unconnected rows

Just move the condition on the left joined table from the where clause to the on part of the join:

SELECT ...
FROM curriculum c
LEFT JOIN transcript t 
    ON c.Course_Code = t.Course_Code and t.CWID = "C38475920";

Conditions in the where clause are mandatory, so the way you phrased the query actually turned the left join to an inner join: if a curriculum had no transcript, the where clause evicts the corresponding row.

---

Related Topics