Ciekawostki cz. 1

Dzisiaj będę się chwalił się swoją niewiedzą. Kilka dni temu kolega zadał mi pytanie, którym skutecznie mnie zagiął. Ponieważ uważam, że głupotą nie jest brak wiedzy co raczej udawanie, że się ją posiada, czym prędzej się Wam tym pytaniem chwalę. 

Co zostanie wyświetlone po takim kodzie i dlaczego? 

string string1 = "Test";

string string2 = string1;
string string3 = "Test";

Console.WriteLine(Equals(string1, string2)); // 1.
Console.WriteLine(Equals(string1, string3)); // 2.
Console.WriteLine(ReferenceEquals(string1, string2)); //3.
Console.WriteLine(ReferenceEquals(string1, string3)); //4.

Odpowiedź 
(Pokaż)

Pierwsze i drugie porównanie pokażą oczywiście true - Equals porównujący stringi o tej samej wartości zawsze pokaże true

Drugi i trzeci pokażą również true - tutaj był mój błąd. Uznałem, że skoro string nie jest typem referencyjnym to przy przepisaniu skopiuje on wartość, a nie przepisze referencję. W teorii tak powinno być, ale w tym momencie do gry wchodzi Optymalizator Kompilacji. Ten byt czuwa nad tym, aby nasz program działał jak najszybciej maskując ile się da nasze błędy. W tym przypadku zauważył, że nie ma sensu tworzyć nie wiadomo ile obiektów, skoro i tak string ma przeładowaną metodę Equals i operatoror porównywania. Zamiast generować kolejne obiekty poprzypinał on referencje do jednego obiektu.
Optymalizator jest na tyle sprytny, że potrafi się obronić przed takimi trikami:

string string4 = string1 + String.Empty;

Console.WriteLine(ReferenceEquals(string1, string4));

Dla powyższego kodu również wyświetli true.
Dopiero coś takiego potrafi go wprawić w konsternację i każe mu wyświetlić upragniony false:

string string5 = (string3 + "a").Replace("a", String.Empty);

Console.WriteLine(ReferenceEquals(string1, string5));

(Ukryj)

Błąd "Cannot update a parent row: a foreign key constraint fails" przy pobieraniu rekordów w NHibernate

Dzisiaj kolejny krótki wpis, ponownie dotyczący NHibernate'a.
Jak pewnie zdążyliście zauważyć jest to coś co ostatnio sprawia mi najwięcej problemów.

Próbując pobrać rekordy przy pomocy zwykłego selecta zawężonego o kryteria w NHibernate, otrzymałem zaskakujący błąd 

"Cannot update a parent row: a foreign key constraint fails"

Pierwsza moja myśl była: "Pobieram rekordy, a on chce robić update? Jak to, zgłupiał?!".
Miałem klasę zdefiniowaną jako:

public class KontoBankowe
{
    public virtual int    Id           { get; set; }
    public virtual int    Oprocentowanie     { get; set; }
    public virtual int    IdBanku { get; set; }
}

oraz mapowanie klasy jako:

public class KontoBankoweMapowanie : ClassMap<KontoBankowe>
{
    public KontoBankoweMapowanie()
    {
        Table("KontoBankowe");
        Id(e => e.Id);
        Map(e => e.Oprocentowanie, "Nazwisko").Not.Nullable();
        Map(e => e.IdBanku , "IdBanku ");
    }
}

Widzicie już co jest źle? Jeżeli tak, to bardzo Wam gratuluję, bo mnie to chwilę zajęło.
Dla równie opornych na wiedzę jak ja, tłumaczenie:
1. Pobieramy wiersze konta bankowego.
2. Wśród rekordów mamy wiersze, które w kolumnie IdBanku mają nulle (tabela i mapowanie na to pozwalają).
3. Po pobraniu nulla NHibernate ustawia wartość właściwości IdBanku klasy KontoBankowe jako domyślna wartość typu int, czyli 0.
4. Ponieważ encja pobrana przez nas jest różna od tej, która jest w bazie (0, zamiast null) to NHibernate przy wywołaniu metody Session.Flush() próbuje uaktualnić pobrany rekord. Nie istnieje, żaden bank o id równym 0, więc update wyrzuca błąd na kluczu obcym łączącym tabelę KontoBankowe z tabelą Bank.

Rozwiązanie problemu jest proste. Wystarczy w klasie KontoBankowe ustawić pole IdBanku jako int ?. Po poprawkach klasa będzie wyglądała:

public class KontoBankowe
{
    public virtual int    Id           { get; set; }
    public virtual int    Oprocentowanie     { get; set; }
    public virtual int ?  IdBanku { get; set; }
}

Do zapamiętania: Zawsze sprawdzać czy ustalone pole jako nullable jest typem, który może przyjąć wartości null (ze szczególnym uwzględnieniem typów prostych i struktur).

Jak odblokować workspace w TFS

Dzisiaj kolejny przykład z życia wzięty, krótszy ale miejmy nadzieję, przydatny. Zmieniłem na swoim komputerze nazwę grupy roboczej, do której należę. Po uruchomieniu Visual Studio i próbie checkoutu pliku okazało się, że pojawił mi się komunikat o błędzie:

A local workspace is required.  
Workspace NazwaGrupyRoboczej;Nazwa użytkownika 
does not reside on this computer.

Komunikat ni mniej ni więcej mówi, że VS nie mogło odnaleźć wcześniejszego workspace'a. Powodem jest to z tego, że TFS cache'uje workspace'y. Jak zatem wymusić na żeby odświeżył je i zobaczył naszą zmianę?

Należy uruchomić Visual Studio Command Prompt (Start => Programy => Microsoft Visual Studio 2010 => Visual Studio Tools => Visual Studio Command Prompt (2010)) i wpisać w nim:

tf workspaces /s:URLDoTwojegoSerweraTFS

I już.