Is it possible to parse criteria from string?
You're not giving anyone much to go on, so I'll just have to take a guess at what you're trying to ask...
If you're looking for a simple criteria.Parse("string here"); then no, I don't such a thing exists.
However, the criteria interface lends itself very well to dynamic creation (in fact, that's its intended purpose). As such, yes, you could write a string parser to create ICriteria elements from tokens.
Perhaps if you provide more information on the problem you are trying to solve someone can respond with a better answer.
Related
I like to use keyword where, for example.
I simply do it like this
Dim orderFromThisGridTrading = _orders1.Where(Function(x) x.customIdentifier = ASimpleGridTradeSettings.name).ToArray
However, most samples would say I have to use from
Dim customersForRegion = From cust In customers Where cust.Region = region
Which is weird af and don't follow normal vb.net format. That looks a like like SQL languages and not a real programming language.
I wonder if I can always avoid using Form and just use like I am using? Are there any cases where that is not possible?
Is this even a good idea?
There is nothing bad in using query syntax in general. Especially in VB.NET it is very powerful and supports a lot of LINQ methods(more than in C#). Many prefer that because it can make your code more readable. But it seems that the opposite is true for you, you don't like it. Then use the method syntax, it supports all methods. I don't like it in VB.NET because of that ugly and verbose Function keyword, especially with GroupBy or Join i prefer query syntax.
I wonder if I can always avoid using From and just use like I am
using? Are there any cases where that is not possible?
No, method syntax is always possible. Actually query syntax gets compiled to method syntax.
The second example is called "Query Comprehension Syntax". It's optional. A lot of people find it makes their code more readable, but not everyone likes it. Personally, I find it adds another extra layer of indirection for what you need to know to get the computer to do what you want.
In the first example, the "From" is implied by the intial IEnumerable or IQueryable item in the expression.
But I do have one issue:
SQL is definitely a real programming language, and you'll likely get even better results from learning it well vs needing to rely on an ORM to construct queries. Eventually, usually sooner than later, you'll find you want to do something where you need to know advanced SQL anyway. Then you have two problems, because you need to the know the SQL and you need to know how to construct the ORM syntax to produce that SQL.
I wonder if there's a way to prevent the creation of objects that contain old ansi sintax of join, maybe server triggers, can anyone help me?
You can create a DDL trigger and mine the eventdata() XML for the content of the proc. If you can detect the old syntax using some fancy string-parsing functions (maybe looking for commas between known table names or looking for *= or =*), then you can roll back the creation of the proc or function.
First reaction - code reviews and a decent QA process!
I've had some success looking at sys.syscomments.text. A simple where text like '%*=%' should do. Be aware that long SQL strings may be split across multiple rows. I realise this won't prevent objects getting in there in the first place. But then DDL triggers won't tell you how big your current problem is.
Although I fully understand your effort, I believe that this type of actions is the wrong way of getting where you want. First of all, you might get into serious trouble with your boss and, depending of where you work, get fired.
Second, as stated before, doing code reviews, explaining why the old syntax sucks. You have to have a decent reason why one should avoid the *= stuff. 'Because you don't like it' is not a feasible argument. In fact, there are quite some articles around showing that certain problems are just not solvable using this type of syntax.
Third, you might want to point out that separating conditions into grouping (JOIN ... ON...) and filtering conditions (WHERE...) increases the readability and might therefore be an options.
Collect your arguments and convince your colleagues rather than punishing them in quite an arrogant way.
I would like to create my own query language for a web api I wrote. But I have no idea where to start for it.
The language should be like SQL. For that I looked up the NHibernate code, cause I know, that they have the HQL (Hibernate Query Language) but it didn't help.
Are there any instructions or sth.? If this question is wrong here please move and/or tell me where I should ask else.
The first step is a lot of design work, starting be answering the following question:
Is this new Query Language going to be converted to SQL which will be
executed by a standard database engine, or are you going to write your
own database server as well?
If it's going to be converted to SQL (just like HQL) then map out the translations from your language to SQL on paper (and make sure you know the possible SQL constructs you may have to use). Once you've got that, you can start implementing it. Yes, this sounds like BDUF, but the language should be defined in one pass, I think, as it will be more consistent and easier to use if you do it that way. You can always implement it in a more Agile way once you've got that.
If you're going to write own database server, you're on your own....
With beta4 and latest beta5 the DB-Feature-Implementation appears to have pretty much finished. There's a couple of tutorials out there how to handle a single Database using the TableGateway Pattern, but it appears there is none for handling M-N-Relationships.
In ZF1 we had findDependantRowset() on the TableGateway which was kind of dirty, as this simply was a second Query to the databse which pretty much isn't always neccessary.
In ZF2 i expected there to be a way to have good Joins mapping to specified models, but i can't find anything within the code. Maybe i'm blind, maybe there really isn't anything like this.
Has anyone of you managed to handle joins and models all together in ZF2? If so, please be so kind to instruct me how to do it, hint me to specific points of the documentation or link me some blogpost to one who has done it.
Thanks in advance guys!
The obvious solution if you need a generic solution is to use Doctrine ORM or Propel.
If you want to use Zend\Db, then within your concrete table gateway classes, you should write a specific method that retrieves the correct rows from the linked table. This way you can ensure that the SQL is optimised for the query that you need.
There are a multitude of key-value stores available. Currently you need to choose one and stick with it. I believe an independent open API, not made by a key-value store vendor would make switching between stores much easier.
Therefore I'm building a datastore abstraction layer (like ODBC but focused on simpler key value stores) so that someone build an app once, and change key-value stores if necessary. Is this API too simple?
get(Key)
set(Key, Value)
exists(Key)
delete(Key)
As all the APIs I have seen so far seem to add so much I was wondering how many additional methods were necessary?
I have received some replies saying that set(null) could be used to delete an item and if get returns null then this means that an item doesn't exist. This is bad for two reasons. Firstly, is it not good to mix return types and statuses, and secondly, not all languages have the concept of null. See:
Do all programming languages have a clear concept of NIL, null, or undefined?
I do want to be able to perform many types of operation on the data, but as I understand it everything can be built up on top of a key value store. Is this correct? And should I provide these value added functions too? e.g: like mapreduce, or indexes
Internally we already have a basic version of this in Erlang and Ruby and it has saved us alot of time, and also enabled us to test performance for specific use cases of different key value stores
Do only what is absolute necessary, instead of asking if it is too simple, ask if it is too much, even if it only has one method.
Your API lacks some useful functions like "hasKey" and "clear". You might want to look at, say, Python's hack at it, http://docs.python.org/tutorial/datastructures.html#dictionaries, and pick and choose additional functions.
Everyone is saying, "simple is good" and that's true until "simple is too simple."
If all you are doing is getting, setting, and deleting keys, this is fine.
There is no such thing as "too simple" for an API. The simpler the better! If it solves the need the way it is, then leave it.
The delete method is unnecessary. You can just pass null to set.
Edited to add:
I'm only kidding! I would keep delete, and probably add Count, Contains, and maybe an enumerator (or two).
When creating an API, you need to ask yourself, what does my API provide the user. If your API is so simplistic that it is faster and easier for your client to write their own app, then your API has failed. Ask yourself, does my functionality give them specific benefits. If the answer is no, it is too simplistic and generic.
I am all for simplifying an interface to its bare minimum but without having more details about the requirements of the system, it is tough to tell if this interface is sufficient. Sure looks concise enough though.
Don't forget to document the semantics for "key non-existent" as it isn't clear from reading your API definition above. updated: I see you have added the exists method: is this necessary? you could use the get method and define a NIL of some sort, no?
Maybe worth thinking about: how about considering "freshness" of a value? i.e. an associated "last-modified" timestamp? Of course, it depends on your system requirements.
What about access control? Is it within scope of the API definition?
What about iterating through the keys? If there is a possibility of a large set, you might want to include some pagination semantics.
As mentioned, the simpler the better, but a simple iterator or key-listing method could be of use. I always end up needing to iterate through the set. A "size()" method too, if not taken care of by the iterator. It obviously depends on your usage, though.
It's not too simple, it's beautiful. If "exists(key)" is just a convenient shorthand for "get(Key) != null", you should consider removing it. I guess that depends on how large or complex the value you get() is.