Hej jag är ute efter lite artiklar och kodexempel om hur man kan bygga en
sökmotor mot objekt med reflektion. Så att jag kan skriva liknande sql satser mot en objektmodell.

Jag är inte ute efter att lägga in datan i en datatable eller dataset. Men jag är ute efter liknande funkionalitet fast med en objektmodell.

Nu chansar jag...

Det jag kom och tänka på först är Predicate<T> och LINQ i C# 3.0 men jag antar att du vill skriva mer likt SQL som en sträng "select propertyOne from myList" isåfall kanske NHibernates HQL skulle kunna vara en bra uppslagskälla?

Ja det är typ HQL jag är ute efter, eftersom användaren skall kunna skapa egna frågor.
Jag har funderat på att kika på NHibernate's funktionalitet när det gäller detta, men det hade underlättat med någon artikel om det utan att bara gräva i deras kod.

Kanske kan detta vara något? http://www.codeproject.com/cs/library/Karmencita.asp

Sedan använder NPersist NPath som är ett likande frågespråk som HQL, tror man kan ladda ner NPath för sig själv http://www.puzzleframework.com/.

Idag fann jag NLinq, så där har du ett ytterligare projekt att kolla på http://www.codeplex.com/nlinq

Tack, det som hade varit grymt bra är om den hade kunnat vara väldigt lik de sqlsatser man kan skriva med t.ex. join, sum osv.. så att man kan få motorn att skapa objekt ungefär så som linq fast man kan skriva queries.

Skall på det du precis la in, måste säga att NPath var grymt snabb vid enklare frågor.

>>måste säga att NPath var grymt snabb vid enklare frågor.

/Flex

Vi emittar metoder för att läsa av värdena på properties i NPath
så det bör gå betydligt snabbare än via vanlig reflection (propertyinfo.getvalue)

NPath har inte stöd för joins som sql , däremot kan man traversera property paths.
tex:

where
order.customer.streetname like '%bla%'

och subqueries

select *
from Customer
where
(select count(*) from Orders where orderdate > #2007-01-01#) > 2

^ i det fallet förutsätter den att "Orders" är en collection property på Customer

Okej, det som hade varit intressant är om man hade kunnat få NPath att bygga en klass beroende på vad man skriver istället för * t.ex.
Select Cutomer.Name, Order.Name From Customer Where....

Men antar att det inte går då?

Det går nog med lite handpåläggning.

Vi har stöd för "TabularQueries" där man ställer en fråga mot en objektgraf , men får ut en datatable

tex:

select FirstName + ' ' + LastName as Name
from User
Where blablabla

Om man kör den frågan som tabular så kommer vi få en datatabell med en kolumn som heter "Name" som är en ihopslagning av first o lastname.

Så det är ju absolut inte omöjligt att runtime emitta klasser med samma properties.
även om det vore lite halvt meningslöst eftersom du inte skulle ha tillgång till dessa i designtime.
Inte i C# iaf.

I VB.NET går det ju köra latebinding och där skulle man absolut kunna accessa dessa properties i designtime med, fast utan intellisense då..

//Roger

Med vi menar du NPath?

Får gräva mig ner lite mer i det, att få ut en datatable skulle absolut fungera, om den också klarar av SUM osv :)..?

Jag kan ge ett exempel på vad jag är ute efter säg att jag har ett

Konto som har ett kontonummer, ett konto kan ha flera transaktioner.

Säg att jag vill räkna samman alla transaktioner för ett par konton som ligger inom ett visst intervall t.ex. konto-nummer 203-220. Är det möjligt?

JA, i det här fallet är "vi" = NPath.
Det är jag och Mats Helander som bygger det , alltså "vi" :)

Okay, hittade en liten bugg i den tror jag. Kan återkomma om exakt var imorgon.

        public override bool Equals(object obj)
        {
            KeyStruct other = (KeyStruct) obj;

            for (int i = 0; i < keys.Length; i++)
            {
                if (keys[i] != other.keys[i])
                    return false;
            }

            return true;
        }

När jag använder exemplet med personer och addresser som följer med NPath och byter ut metodanropet mot propertyn. Så retuneras aldrig true varje gång i MultiHashTable även om det stämmer överens, detta betyder att vid många objekt så tar det enormt lång tid eftersom denna används när man skall avgöra om man behöver skapa en ny PropertyAccessor eller inte. Jag provade snabbt att ändra koden till detta.

        public override bool Equals(object obj)
        {
            KeyStruct other = (KeyStruct) obj;

            for (int i = 0; i < keys.Length; i++)
            {
                if (keys[i].ToString() != other.keys[i].ToString())
                    return false;
            }

            return true;
        }

Detta löste problemet, även om det kanske inte är rätt väg att gå.
Tar gärna lite feedback på detta om detta är ett fel eller inte så jag vet om jag skall ändra tillbaka eller ej,

jag har checkat in en fix i vår SVN.

public override bool Equals(object obj)
{
    KeyStruct other = (KeyStruct) obj;

    for (int i = 0; i < keys.Length; i++)
    {
        object thisKey = keys[i];
        object thatKey = other.keys[i];

        if (Comparer.Default.Compare(thisKey,thatKey)!=0)
            return false;
    }

    return true;
}

Jag tror den ska lösa problemet.

Jag har insett att NPath inte täcker mitt behov när det gäller att hämta data ur min objektmodell, Däremot gör HQL det, problemet är bara att jag tycker att den inte är tillräckligt löst kopplad mot NHibernate. Jag vill ha en sökmotor i min objektmodell utan en databas.

Vad är det för funktionallitet du saknar i NPath?

eller är det navigering av property paths som inte räcker?

Jag kanske har missat det i NPath,

men jag vill kunna skriva queries liknande dessa.

SELECT new CustomerResult(c.Name, c.Phone, c.PrimaryAddress.Line1, c.LastOrderDate) FROM Customer AS c

Där jag också kan använda lite join och groupby.

Jag funderar nu visserligen lite på Linq

Men fungerar liknande queries i NPath så är jag extremt intresserad.

Måste tacka för dina svar.

Just att få ut det i nya objekt är inget som finns i NPath, det handlar ju mer om vad man gör med datan som kommer ut.

hur som, NPath har stöd för tabular queries, så man kan få ut aggregerat data.
och vi har stöd för subqueries.

så man kan tex göra:

select sum (select quantity * itemprice from Details) as OrderTotal , OrderDate
from Order


där är "Details" i subqueryn en collection prop på Order
och därmed behövs inga joins eller group by osv.

Har du något konkret exempel på fråga där du anser att group by eller speciella joins behövs?

I en domänmodell så har man ju inbyggda relationer, så jag ser inte riktigt varför joins behövs där.
om du är intresserad av att joina ihop data så borde det ju ingå som en naturlig relation i din DM.

Hur som , vore väldigt intressant om du har något fall där subqueries och propertypaths inte skulle täcka det du vill göra.