Is it possible in DQL to do a LIKE query that ignores accents? Searching for a word that has an accent should return accented and non accented versions.
My question is similar to this one in the emc forums. Any solution ?
I am not familiar with solution for this kind of requirement at DQL/translated SQL level.
Maybe you could write your views, and maybe you could write procedures at DB level to achieve this, but this wouldn't be clean solution.
Maybe if you could specify your client over you execute your DQL it could be more clearer what could be done at client level.
I remind you that DQL queries depends on translation to underlying DB SQL flavor. If there are known solutions at DB level, maybe you could use them for your specific situation. Try adding new tags on your question regarding underlying DB.
Related
note: this Q is looking for a comparison of Hibernate named queries and ordinary session queries. Hibernate Criteria is of no concern within the context of this Q.
from what i know, named queries are those parsed once when the system starts up, and can be used from everywhere throughout the application. so - w/named queries, the query isn't parsed from scratch for each caller of that query and this is the major gain in named queries.
but then -
is there a difference between how Hibernate operates its caches for named- and ordinary-queries? if so- what is this?
is there any loss in turning ordinary Hibernate queries into named-queries?
i've had a discussion w/a colleague. he thinks that, before i should go turning ordinary queries into named queries, i should device some metrics and write tests just to prove how named-queries is performing better.
i think this-- generating metrics and writing tests just for the sake of measuring how/whether named queries perform better than ordinary queries is nothing but burning time into something useless. that's been shown already-- the reason of existence of named queries is just getting the query parsed. what data it's pulling/changing in DB is immaterial. and, Hibernate named queries is being used by many developers.
my Q is -
am i missing something in named queries that is relevant to this discussion?
opinions on how to handle this situation? the options i'm looking at are i.) drop doing anything at all-- let queries as is, ii.) just change named queries-- reverting if disliked wont have burned too much of my time iii.) do those tests-- if i would consider this as an option.
TIA.
Short answer - Use it if you can. But if you already have queries that are working fine with tests that cover its functionality, I wouldn't recommend that you go converting them.
Another SO post addressing this can be found here:
Advantages of Named queries in hibernate?
My application has a complex schema for the domain entity. It is required use SQL Server 2008. Following are the complexities:
Domain Entity is Hierarchical: The data structure is a tree; it is nested to many levels. Few nodes in the tree are repeatable (multi-valued). For example, the entity can have unlimited addresses (home, billing, shipping, office, etc.)
Domain Entity is Expandable: The schema may expand (not shrink) in future.
Designing such a schema directly as related SQL Server tables is quite challenging. If not designing, quering will surely be so.
I am thinking of using XML type to store the domain entity records. However I have following queries:
Due to peculiar reporting needs, each field should be query-able (within and across entity records). This applies to even the fields that are added in future to the schema.
While using XML type, since I lose the structure, what is the best Data Access Layer I can design?
Can I use Entity Framework effectively in this situation?
Any best practices recommended?
One advice: DO NOT DO IT. Seriously. You are already down a slippery slope - etter learn to use databases.
The "Domain Entity" you define here will be large, which means that querying it will be a challenge.Unlimited addresses means 100.000 plus that you ahve to be prepared to. Anyone stupid enough to ask for the xml document will get a bad surprise, as will the server.
You also loose a lot of tooling left and right - from ORM's to reporting tools. Simply because you abuse wthe XML support the databae has (which is planned to store documents, not act as pseudo database).
Your queries:
Due to peculiar reporting needs, each field should be query-able (within and across
entity records). This applies to even the fields that are added in future to the schema.
In the english language, this is not a query, you know. It is also not possible.
While using XML type, since I lose the structure, what is the best Data Access Layer I can design?
Start writing SQL. By hand. Or develop your own. You are way out of what people use XML For, so no predefined tooling support.
Can I use Entity Framework effectively in this situation?
Obviously no.
Any best practices recommended?
Yes, learn using SQL Server properly. This is NOT a good approach.
I'm working on an abstraction layer for this:
http://rogeralsing.com/2011/02/28/linq-to-sqlxml/
Code is available on https://github.com/rogeralsing/linq-to-sqlxml
You can query and select/project entities from Sql server XML columns.
We are using it for evolving entity schemas while keeping old versions intact.
That beeing said, we only use it for special cases and go O/R mapping as a default approach.
In all honesty, and whilst I see #TomTom 's point, but it depends whether it is just ONE xml document or not. With 2008, you can setup XML schema's and map them to an XML field.
In contrary to TomTom 's answer, you can query an xml data field like you would do normally. Check the following SO answer for more information: https://stackoverflow.com/questions/966441/xml-query-in-sql-server-2008
You can use the entity framework (my knowledge is a bit short on this), by making some sproc's to query your data, then call the sproc from code and cast it to an XDocument. Not the prettiest way of doing it but it should work. Note: there might be another way of doing this, but that's as far as my knowledge of EF goes, perhaps add a tag for EF in the question?
I guess you need to come back to us and state whether you need to query 1 xml document (in which case an relational DB would possibly be better, suggested by #TomTom) or multiple documents (which I would use SQL Server to do the work. Chances are you'll have some way of linking these documents together anyway).
XML indexing tips can be found here
And some more info on XML in SQL 2008 here
Hth,
Stu
Did you try SisoDb? If you have any questions about it I would happily answer them. Use the contact form at http://www.sisodb.com or ping me at Twitter.
For the first time in years I've been doing some T-SQL programming in SQL Server 2008 and had forgotten just how bad the language really is:
Flow control (all the begin/end stuff) feels clunky
Exception handling is poor. Exceptions dont bubble in the same way they do in every other language. There's no re-throwing unless you code it yourself and the raiserror function isn't even spelt correctly (this caused me some headaches!)
String handling is poor
The only sequence type is a table. I had to write a function to split a string based on a delimiter and had to store it in a table which had the string parts along with a value indicating there position in the sequence.
If you need to doa lookup in the stored proc then manipulating the results is painful. You either have to use cursors or hack together a while loop with a nested lookup if the results contain some sort of ordering column
I realize I could code up my stored procedures using C#, but this will require permissioning the server to allow CLR functions, which isn't an option at my workplace.
Does anyone know if there are any alternatives to T-SQL within SQL Server, or if there are any plans to introduce something. Surely there's got to be a more modern alternative...
PS: This isn't intended to start a flame-war, I'm genuinely interested in what the options are.
There is nothing wrong with T-SQL; it does the job it was intended for (except perhaps for the addition of control flow structures, but I digress!).
Perhaps take a look at LINQ? You can write CLR Stored Procedures, but I don't recommended this unless it is for some feature that's missing (or heavy string handling).
All other database stored procedure languages (PL/SQL, SQL/PSM) have about the same issues. Personally, i think these languages are exactly right for what they are intended to be used for - they are best used to do code data-driven logic, esp. if you want to reuse that for multiple applications.
So I guess my counter question to you is, why do you want your program to run as part of the database server process? Isn't what you're trying to do better solved at the application or middle-ware level? There you can take any language or data-processing tool of your choosing.
From My point of view only alternative to T-SQL within SQL Server is to NOT use SQL Server
According to your point handling stings whit delimiter ,
From where cames these strings ?
You could try Integration services and "ssis packages" for converting data from one to other.
Also there is nice way to access non SQL data over Linked Serves,
Background: Okay, so I'm looking for what I guess is an object database. However, the (admittedly few) object databases that I've looked at have been simple persistence layers, and not full-blown DBMSs. I don't know if what I'm looking for is even considered an object database, so really any help in pointing me in the right direction would be very appreciated.
I don't want to give you two pages describing what I'm looking for so I'll use an example to illustrate my point. Let's say I have a "BlogPost" object that I need to store. Something like this, in pseudocode:
class BlogPost
title:String
body:String
author:User
tags:List<String>
comments:List<Comment>
(Assume Comment is its own class.)
Now, in a relational database, author would be stored as a foreign key pointing to a User.id, and the tags and comments would be stored as one-to-many or many-to-many relationships using a separate table to store the relationships. What I'd like is a database engine that does the following:
Stores related objects (author, tags, etc.) with a direct reference instead of using foreign keys, which require an additional lookup; in other words, objects on top of each other should be natively supported by the database
Allows me to add a comment or a tag to the blog post without retrieving the entire object, updating it, and then putting it back into the database (like a document-oriented database -- CouchDB being an example)
I guess what I'm looking for is a navigational database, but I don't know. Is there anything even remotely similar to what I'm thinking of? If so, what is it called? (Or better yet, give me an actual working database.) Or am I being too picky?
Edit:
Just to clarify, I am NOT looking for an ORM or an abstraction layer or anything like that. I am looking for an actual database that does this internally. Sorry if I'm being difficult, but I've searched and I couldn't find anything.
Edit:
Also, something for the JVM would be excellent, but at this point I really don't care what platform it runs on.
I think what you are describing could easily be modeled in a graph database. Then you get the benefit of navigating to the nodes/edges where you want to make changes without any need to retrieve anything else. For the JVM there's the Neo4j open source graph database (where I'm part of the team). You can read about it over at High Scalability, as part of an overview at thinkvitamin or in this stackoverflow thread. As for the tags, I think storing them in a graph database can give you some extra advantages if you want to find related tags and similar stuff. Just drop a line on the mailing list, and I'm sure the community will help you out.
You could try out db4o which is available in C# and Java.
I think our looking for this: http://www.odbms.org/. This site has some good info on Object Databases, including Objectivity, which is a pretty good object database.
Elephant does this: http://common-lisp.net/project/elephant/
Exactly what you've described can be done with (N)Hibernate running on an ordinary RDBMS.
The advantage of using such a persistence layer with an ordinary database is that you have a standard database system combined with convenient programming. You declare your classes in a very natural way, and (N)Hibernate provides a way to translate betweeen references/lists and foreign key relationships.
Java tutorial: http://docs.jboss.org/hibernate/stable/core/reference/en/html/tutorial-firstapp.html
.NET tutorial: https://web.archive.org/web/20081212181310/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/04/01/your-first-nhibernate-based-application.aspx
If you insist that you don't want to use a well-supported standard RDBMS and would rather trust your data to something more exotic and less heavily tested, you're looking for an Object Relational Database.
However, such a product would probably be best implemented by making it be a layer over a standard RDBMS anyway. This is probably why ORMs like (N)Hibernate are the most popular solution - they allow standard RDBMS software (and widely available management/user skills) to be applied, and yet the programming experience is 99% object-based.
This is exactly what LINQ was designed for.
Microsoft LINQ defines a set of proprietary query operators that can be used to query, project and filter data in arrays, enumerable classes, XML (XLINQ), relational database, and third party data sources. While it allows any data source to be queried, it requires that the data be encapsulated as objects. So, if the data source does not natively store data as objects, the data must be mapped to the object domain. Queries written using the query operators are executed either by the LINQ query processing engine or, via an extension mechanism, handed over to LINQ providers which either implement a separate query processing engine or translate to a different format to be executed on a separate data store (such as on a database server as SQL queries (DLINQ)). The results of a query are returned as a collection of in-memory objects that can be enumerated using a standard iterator function such as C#'s foreach.
There's a variety of terms, all linked to Object-Relational Mapping, aka ORM, which is probably going to be the most useful one for you to look up. ORM libraries exist for many programming languages.
Oracle's nested tables provide some part of that functionality, though in updates, you cannot just add a row to the nested table - you have to replace the whole nested table.
I guess you're looking for an ORM with "EntityFirst" approach.
In EntityFirst approach the developer is least[not-at-all] concerned with Database. You just have to build your entities or objects. The ORM then takes care of storing the entities in Database and retrieving them at your will.
The only EntityFirst ORM witihn my knowledge "Signum". It's a wonderful framework built on top of .net. I recommend you to go thrgouh some videos on the SignumFramework website and I'm sure you'll find it useful.
Link Text: http://www.signumframework.com
Thanks.
ZODB perhaps?
good introduction find here:
http://www.ibm.com/developerworks/aix/library/au-zodb/
You could try out STSdb, DB4O, Perst ... which is available in C# and Java.
We have a set of applications that work with multiple database engines including Sql Server and Access. The schemas for each are maintained separately and are not stored in text form making source control difficult. We are interested in moving to a system where the schema is stored in some text-based format (such as XML or YAML) with descriptions of field data types, foreign key relationhsips, etc.
When all is said and done, we want to have a single text file in source control that can be used to generate a clean database that works with both SQL Server, Access at least (and preferably is capable of working with Oracle, DB2 and other engines).
I'm certain that there are tools or libraries out there that can get us at least part of the way there. For one, I've found Altova MapForce that looks like it may do the trick but I'm interested in hearing about any alternative tools or libraries or even entirely different solutions for those in the same predicament.
Note: The applications are written in C++ and ORM solutions are both not readily available in C++ and would take far too long to integrate into our aging products.
If you don't use a object relational mapper that does this (and many other things for you) the easiest way might be to whip up a few structures to define your tables and attributes in some form of (static) code and write little generators to create actual databases from that description.
That makes it easy for source control, and if you're careful when designing those structures, you can easily re-use them for other DBs if need arises.
The consensus when I asked a similar (if rather more naive) question seem to be to use raw SQL, and to manage the RDMS dependencies with an additional layer. Good luck.
Tool you're looking for is liquibase. No support for Access though...