|
Hi, can you give me the full example on how using your object with datatable. i already connected to database, but i confuse on how to use it. i want "select distinct", and when i look in your code, there is a "distinct". please help me
|
|
|
|
|
We have a similair but more powerful project called NPath
It is pretty much identical to sql with the difference that you traverse property paths instead of writing joins.
eg:
Select *
from MyListOfOrders
where
Customer.Address.StreetName like '%foo%'
this will traverse and filter on the order.customer.address relation in the object graph.
NPath also supports expressions , sorting and methodcalls etc.
you can also query tabular data and fetch get a datatable
select FirstName,LastName,Address.StreetName as Street
from EmployeeList
a demo can be found here:
http://blogs.wdevs.com/phirephly/archive/2006/02/03/12096.aspx[^]
NPath is intended to be used as an OQL for O/R mappers and alike.
We use it in NPersist to query the database for objects.
the in mem facility is just an extra feature, not the main purpose..
//Roger
http://www.puzzleframework.com
|
|
|
|
|
and even benchmarked it
What I found out is that is horibly unoptimised. Execution times compared to the delegate method are between 50 and 200 times slower on arrays with 1.000 to 100.000 elements and with 3 to 5 comparison expressions in the query.
Also it is highly inflexible, and doesn't allow only but the simples't of expresions.
- No expression grouping either.
- No conversions or casts built in.
- No metod cals on objects just fiels or properies can be present in the query.
- Very hard (imposible?) to query using data from outside the queried collection. Ex: "StoredDate < - DateTime.Now" - doesn't work;
- No knowlege or evaluation of framework types.
- No matematical or complex boolean expressions.
So realy what's the point of this ? there are so many other ways to do it even if not the same ways for all data types.
Sorry Karmencita won't make life easier for me but allot harder if I shoud use it.
|
|
|
|
|
I see it as a proof of concept - give the guy some time. If there's enough support and interest in this, he'll extend it over time. I see it becoming very powerful for dynamic queries in the future. That'll likely be my only use for it, but it's a good use.
PS: This is what part of the alphabet would look like if the letters Q and R were removed.
|
|
|
|
|
oh - and as far as mathmatical expression evaluation goes, check this out -- http://www.codeproject.com/csharp/expressionevaluator.asp[^]. This is quite possibly the best string-parsing expression evaluator I've seen, and it's extensible out of the box. Might be neat to try to tie these two projects together.
PS: This is what part of the alphabet would look like if the letters Q and R were removed.
|
|
|
|
|
If you are looking for a query engine for DataTables, DataSets and XML documents, you might want to look at www.queryadataset.com. It provides full SQL SELECT/UNION syntax, joins, functions, grouping and sub-queries. Its an excellent tool for developers who want to write less code when interacting with a DataSet.
While this and LINQ are great concepts, they do force you to hard code your queries or expressions.
|
|
|
|
|
Why won't you guys cut it out?.
No hard feelings but I rather have a piece of code wich I can debug, rather than have all of those weird utilities to do querying in a non intuitive non debugable and non predictable way. Not to mention the perf hit.
That querying stuff isn't worth the loss in control over the code and speed penalty. Not to mention no more compile time error cheching, no refactoring support and very bad overall integration into the programiing model.
|
|
|
|
|
You can use Array.FindAll() with a certain predicate to obtain the same result over any colection, and also have static checking and intelisense.
An example
Process[] procs = Array.FindAll(Process.GetProcesses(), delegate(Process p) {
return (p.BasePriority > 3) && p.Responding && p.MainWindowTitle.StartsWith("C");
});
As for xml your method allone doesn't seem too powerful to allow true hierachical data querying.
|
|
|
|
|
In this case you are limited to Array and List<t>. With Karmencita you can query from any type of data source (the only requirement is that the DataSource implements IEnumerable). Also the "strong typed" alternative can't support DataTables or XmlDocuemnts.
Yes...you're right about hierarchical xml queries. Joins are on my TODO list.
Cheers.
|
|
|
|
|
No you-re not limited to Array and List, you can query any IEnumerable object the same way... even DataTable rows, because the DataTable.Rows collection is IEnumerable
."
-- modified at 10:39 Friday 24th March, 2006
What I meant is you can use the same technique for any IEnumerable not the Array class with IEnumerable ... sorry for the confusion
|
|
|
|
|
Check out the Linq Project[^] if you haven't already. They're making query syntax for C# and VB.NET a first-class language feature, with full intellisense, etc. Some very exciting developments are taking place over there. It looks *very* similar to the work you're doing here.
PS: This is what part of the alphabet would look like if the letters Q and R were removed.
|
|
|
|
|
Hi. 2 things :
- you can use Karmencita today.
- following your way of thinking....why should you spend time with LINQ ? You KNOW that after LINQ will be out there will be something that will surpass LINQ ? Why not wait for that ?
Cheers.
|
|
|
|
|
"you can use Karmencita today."
Technically, I can use LINQ today too. They've got an alpha version of C#3 out that works quite nicely in VS 2005 (if you're willing to do without IntelliSense).
"following your way of thinking....why should you spend time with LINQ ? You KNOW that after LINQ will be out there will be something that will surpass LINQ ? Why not wait for that ?"
LINQ will provide compile-time type checking, full designer support (including IntelliSense), a simpler object model, and with the new features coming with C#3 (lamda expressions, anonymous types, extension methods), there's a lot more sugar to "wait for" that's coming right around the bend.
As for waiting for the "next best thing" - when I see it, I'll start waiting. Right now, LINQ is what's on the horizon, and it's *very* close. Worth the wait, in my opinion, especially considering any project I'll be working on will take several months to complete. If I start now with Karmencita, I'll have to change my code to migrate it to LINQ anyway.
Perhaps my initial title was too harsh. I didn't mean to imply that Karmencita is not a worthwhile venture, or to offend the author in any way; only that the very problem space Karmencita is being developed to tackle is being built in to the C# compiler with the next release, in a way that none of us really have the access to duplicate. Given that the two are so similar in nature, I have to go with the one that provides designer support and doesn't require string parsing at runtime.
I did give this article my 5...
PS: This is what part of the alphabet would look like if the letters Q and R were removed.
|
|
|
|
|
I agree, LINQ is quite powerfull, but Karmencita some advantages over Linq:
1. It is available NOW (for projects which have to ship soon, or new smaller projects). You will NEVER know when Linq is available.
2. Karmencita is easier to use and needs less overhead
3. Karmencita uses strings for queries and thus is more dynamic (but also more error prone and has more security risks)
4. With some effort you can build some sort of ADO.NET layer around Karmencita, since it uses pseudo-SQL, and use it for some sort of in-memory databases.
As you see, Linq and Karmencita are just two different things. Neither is the "best" ))
|
|
|
|
|
@StSz : Well....you pretty much nailed it. I couldn't have said it better myself.
@dzCepheus : Agreed with what you wrote there (maybe except the LINQ's "simpler object model"). Just read StSz comment. Thanks for the 5 rating.
|
|
|
|
|
"You will NEVER know when Linq is available."
-- LINQ will be available publicly when they release Orcas, which will be Q4 this year (so I've heard from various MSFT blogs). Failing that, I'm pretty sure I will know when it's available when it becomes available... :P
"Karmencita is easier to use and needs less overhead"
-- Your first point is opinion, the second I'd like to see backed up by some facts... From what I've seen, LINQ is largely syntactic in nature -- that is, LINQ queries are, when compiled, translated into normal .NET calls on Static extension methods. Karmencita has the runtime requirement of string parsing on calls (not sure how/if Karmencita does any query caching), which adds considerable runtime overhead.
"Karmencita uses strings for queries and thus is more dynamic (but also more error prone and has more security risks)"
-- True, Karmencita is more dynamic than LINQ. If you need a dynamic data query language, that end-users will be writing queries with, then I would definately recommend Karmencita. That's why I gave it a 5 rating in the first place - it solves a problem that LINQ can't. Though as you say, with that flexibility comes security risks - as well as performance issues at runtime with string parsing.
"With some effort you can build some sort of ADO.NET layer around Karmencita, since it uses pseudo-SQL, and use it for some sort of in-memory databases."
-- But LINQ already does this. It's called DLINQ. They also have one for XML called XLINQ. I wouldn't have to expend any effort to use it, and I could start building for it literally today with the preview compiler. Granted I can't use it in production, but that isn't an issue for me because I'm using it with new products we're just beginning to develop.
Also, one of the reasons they're making LINQ is to tie data access in to the C# and VB languages as a first-class being. One of the historic problems with data access currently is that, when you litter your code with SQL command strings for example, if your database schema changes you have to walk through your entire codebase looking for whichever SQL commands you have to change. How does Karmencia help with this, when it too is string-based?
"As you see, Linq and Karmencita are just two different things. Neither is the "best""
-- I never said one was *best*; just that the two systems are extremely similar and lie in the same problem space. One has compile-time support, which results in faster execution, type safety, compile-time checking, language integration, etc. but lacks a dynamic runtime extension model, while the other is dynamically editable at runtime but must be string-parsed with no compile-time support at all.
There are pros and cons to both - I just want people to be aware that there is another solution coming on the horizon.
PS: This is what part of the alphabet would look like if the letters Q and R were removed.
|
|
|
|
|
|
Thanks Marc. I'll look into it.
|
|
|
|
|