KRUPPI: nechybi ti tam strednik za tim localhostem?

Zdravím, potřeboval bych poradit s voláním http api. Konkrétně se serializací dat.

Mám nějaký objekt Foo který nese data, která se snažím se pomocí HttpClient třídy odeslat na api který běží na PHP a akceptuje data jako FormUrlEncoded. Takže můj kód vypadá nějak takhle:

[C#] var url = "http://localhost" var data = new Foo(); var client = new HttpClient - Pastebin.com
http://pastebin.com/hn81L4Ct

tohle mi vyhazuje vyjímku InvalidOperationException s tím, že:

The configured formatter 'System.Net.Http.Formatting.FormUrlEncodedMediaTypeFormatter' cannot write an object of type 'Foo'.

Pochopil jsem, že tenhle formáter je pouze pro to, aby web api fw dokázal bindovat právě form data na objekty a ne obráceně tak jak to potřebuji já. Zajímalo by mě tedy jak správně serializovat ty data?

MORMEGIL: Sorry, nemam. Bylo to nejake me zmateni - napsal jsem to asi lip nez jsem si myslel [:

GOSHEWAN: A opravdu tam máš spoustu velkých shodných stringů…?

Mam dotaz na String.Intern(); - zdedil jsem aplikaci, ktera slouzi jako cache a search engine. Vyhledava v zaznamech podle jednoho jejich atributu, ktery je typu string. Musi umet 'starts with' a 'contains'.
Puvodne pouzivala SortedDictionary<string, Item> na 'starts with' a obycejny Dictionary<string, List<Item>> na 'contains' - pregenerovala si do neho substringy.
Ted jsem to predelal na RadixTree a nejenze to je pametove podstatne lepsi, ale vytvoreni te cache je rychlejsi. Vyhledavani je 'prijatelne' pomalejsi (ma to miliony zaznamu).

Jadro otazky spociva v tom, ze jsem pouzival String.Intern() v domeni, ze to usetri pamet, ale pri pokusu jsem to odstranil a ukazalo se, ze pametova narocnost se vubec nezmenila (!!!). Cele se to tim podstatne zrychlilo, protoze String.Intern() je dost pomale. Jak je ale mozne, ze to zere porad stejne pameti? Nejedna se o literaly...

TOOMIX:

problém se zakódováním kláves vyřešen. Kdyby se to někomu hodilo, tady je řešení, aby se s tim nemusel srát 3 dny, jako já

Při nastavování strignu, který se má zakódovat do barkódu, se nesmí stisk kláves zadávat přímo z ASCII - například $I pro TAB nebo $M pro Enter, ale musí se do stringu dát klávesa v podobě dané tabulkou "ASCII control code chart" z http://en.wikipedia.org/wiki/ASCII Použije se sloupec označen jako C. Takže pokud do barkódu v XtraReports pošlu string ve formátu 123456$I, ze čtečky mi přijde prostý string "123456$I". Pokud tam pošlu string ve formátu 123456\t, barkód z XtraReport si to nějak interně převede a výstupem je napsání 123456 a zmáčknutí TABu.

ROTTWEILER: aj postgre je fajn a ma EF podporu. minimalne na ef5...

ROTTWEILER: A dáváš to na svůj server s IIS? :)) Tak použij SQL express a řekni jim, že to může být pomalé a padat (případně na to svedeš i nějaké své chyby)... A když je to bude štvát, tak ať zaplatí - hosting budou mít za něco přes litr ročně, to mi nepřijde nepřekonatelné pro nikoho...

SLUPKA: Díky za pobídku, ale fakt musí být zdarma. Je to web, který dělám ve svém volném čase pro malou skupinku lidí a nic z toho mít nebudu a určitě do toho nechci dávat peníze.

ROTTWEILER: Já bych doporučil slevit z požadavku "musí být úplně zadarmo" a neřešil bych si server sám, pokud k tomu nemám opravdu dobrý důvod.

SLUPKA: Bylo by tedy lepší se kouknout raději na MySQL?

ROTTWEILER: Prostě počítej s tím, že SQL express nebude efektivní... Na malém webu s malou návštěvností to nemusí být vůbec poznat, já bych to na produkci ale nepoužíval...

SLUPKA: Ano, takový malý web. Velikost databáze maximálně do 50 MB.

ROTTWEILER: Co na té produkci bude? Malý projektík? Pokud ano, tak klidně SQL express. Pokud půjde o něco většího, tak bych rozhodně šáhnul po větším MS SQL.

ROTTWEILER: Tak jasne, ze ho neodporucaju. Keby ano, na "velkom" sql serveri nezarobia.

VIRTUALVOID: Čti jen první větu.

ROTTWEILER: odkedy localdb == sqlexpress ?

VIRTUALVOID: Četl jsem tutorial zde http://www.asp.net/mvc/tutorials/mvc-5/introduction/creating-a-connection-string a píšou tam.

SQL Server Express is not recommended for use in production web applications. LocalDB in particular should not be used for production with a web application because it is not designed to work with IIS. However, a LocalDB database can be easily migrated to SQL Server or SQL Azure.