I have a requirement to retrieve data from RavenDB by using groupby. I am not sure how to apply the query in RavenDB using RQL.
The similar query for SQL Server has been provided, please help me to provide an equivalent RQL Query Statement.
SQL Query "Select count() as Count, key() as UserId from UserTraces where TimeStamp > fromdate and TimeStamp < todate
group by UserId"
Thanks
Related
I wrote a SQL query to design an ORM. Now, I am trying to convert this query to GORM. I read the documentation but I didn't make a proper decision if I use Clouse or conditions.
This is the SQL query I am intending to convert
select collection, count(*) as item_count from collections group by collection order by item_count desc, collection
Thanks in advance.
Something like
db.Select("collection", "count(*) as item_count").Group("collection").Order("item_count desc, collection").Find(&results)
should do the trick. Is that what you are looking for? If not, please comment and clarify.
I have a partitioned table and am trying to limit my search to a few partitions. To do this I am running a query (using legacy SQL) that looks like the following:
SELECT
*
FROM
[project:dataset.table]
WHERE
_PARTITIONTIME >= "2018-07-10 00:00:00"
AND _PARTITIONTIME < "2018-07-11 00:00:00"
AND col IN (
SELECT
col
FROM
[project:dataset.table]
WHERE
_PARTITIONTIME >= "2018-07-10 00:00:00"
AND _PARTITIONTIME < "2018-07-11 00:00:00"
AND col2 > 0)
I limit the main query and the subquery using _PARTITIONTIME, so big query should only need to search those partitions. When I run this query though I get billed as if I'd just queried the entire table without using _PARTITIONTIME. Why does this happen?
UPDATE
The equivalent query using standard SQL does not have this problem, so use that as a workaround. I'd still like to know why this happens though. If it's just a bug or if legacy SQL actually does attempt to access all the data in a table for a query like this.
As noted in the question, switching to #standardSQL is the right solution. You shouldn't expect any big updates to the legacy SQL dialect - while #standardSQL will keep getting some substantial ones.
Also note that there are 2 types of partitioned tables today:
Tables partitioned by ingestion time
Tables that are partitioned based on a TIMESTAMP or DATE column
If you try to query the second type with legacy SQL:
SELECT COUNT(*)
FROM [fh-bigquery:wikipedia_v2.pageviews_2018]
WHERE datehour BETWEEN "2018-01-01 00:00:00" AND "2018-01-02 00:00:00"
you get the error "Querying tables partitioned on a field is not supported in Legacy SQL".
Meanwhile this works:
#standardSQL
SELECT COUNT(*)
FROM `fh-bigquery.wikipedia_v2.pageviews_2018`
WHERE datehour BETWEEN "2018-01-01 00:00:00" AND "2018-01-02 00:00:00"
I'm adding these points to enhance the message "it's time to switch to #standardSQL to get the best out of BigQuery".
I think this is a BigQuery Legacy SQL specific issue.
There is a list of cases for when Pseudo column queries scan all partitions and there is an explicit mentioning of Legacy SQL - In legacy SQL, the _PARTITIONTIME filter works only when ...
I don't see exactly your case in that list - but the best way is just use Standard SQL here
I m doing a query as follows:
SELECT
*
FROM a
WHERE DATEDIFF(D, a.DateValue, DateTimeNow) < 3;
and not working
I m trying to get the data that s not older than 3 days.
SQL server.
How to do this?
DATEDIFF works too slow..
DateDiff is extremely fast... Your problem is you are running it on the database table column value, so the query processor must run the function on every row in the table, even if there was an index on this column. This means it has to load the entire table from disk.
Instead, use the dateAdd function on todays date, and compare the database table column to the result of that single calculation. Now it only runs DateAdd() once, and it can use an index (if one exists), to only load the rows that match the predicate criterion.
Where a.DateValue > DateAdd(day,-3,getdate())
doing this in this way makes your query predicate SARG-able
Microsoft's documentation at http://msdn.microsoft.com/en-us/library/aa258269%28v=sql.80%29.aspx suggests that instead of DateTimeNow you should have getdate(). Does it work any better that way?
Your query doesn't seem to bad. Another way to tackle it would be:
SELECT * FROM a WHERE a.DateValue > DATEADD(dd,-3,GETDATE())
I create a query: Select * from HR_Tsalary where month='3' and year ='2010' the result is 473 records and I found 2 duplicate record, then I create another query to find duplicate record only: SELECT Emp_No, COUNT() FROM HR_Tsalary WHERE year = '10' AND month = '3'GROUP BY Emp_No HAVING COUNT() > 1 the result is zero record from client side (thru Visual Basic Adodb code). But when I use same query from server the result is 2 records. Is there any different when create a query between from server side and client side?
You could start SQL Server Profiler then run your VB code, and see the exact query that's hitting the database and make sure it is what you're expecting.
-Krip
SQL server profile is always open also I identified that from client side some functions are working such as select, order by but some functions are not working such as group by, sum, count, having
Is it possible to use MONTH in a CreateCriteria-statement?
Does NHibernate support YEAR and/or MONTH?
I have a sql-statement like
select obs2.Lopnr from Obs obs2 where MONTH(obs2.Datum)=11)
Best Regards from
Mats
ICriteria supports arbitrary SQL as a restriction. Therefore you could do:
var criteria = session.CreateCriteria(typeof(Obs))
.Add(Expression.Sql("MONTH({alias}.Datum) = ?", 11, NHibernateUtil.Int32);
var results = criteria.List<Obs>();
This will execute a SQL query with {alias} replaced by the alias that NHibernate is using for the Obs table. Of course, this limits your portablility to other databases, as SQL is now embedded in your query.
Another thing to remember is that the names you're using here are the mapped property and class names, not the underlying column and table names.
I don't believe it's possible in a criteria statement. The date functions (year, month, day) are supported in HQL queries so they are usable in that way.