Re: SQLLine

; using SQLLine. Regardless of opinions about whether he should have reached > > for an ETL tool instead, the fact remains that he has a good deal of code > > in production that relies on SQLLine, and it runs. > > > > +1 for an Apache DB subproject and thank you Julian and Ser

Re: SQLLine

ibutions to this tool. > > > On 2021/10/28 21:56, Julian Hyde wrote: > > Drill developers, > > > > The SQLLine community is having a conversation about project > > governance, with options including moving to ASF or an ASF-like PMC > > model. SQLLine has many

SQLLine

Drill developers, The SQLLine community is having a conversation about project governance, with options including moving to ASF or an ASF-like PMC model. SQLLine has many users but very few active developers. If you are a SQLLine user, then you are part of the community, and we would like to hear

MapR nexus server

Hi Drill devs, I’d like to raise a concern from the Calcite dev team. Of course Drill depends on Calcite, but Calcite also depends on Drill: we use drill-fmpp-plugin[1] in our build. This plugin looks for resources in http://repository.mapr.com/maven/

Re: Publish Drill Calcite project artifacts to Apache maven repository

/issues.apache.org/jira/browse/CALCITE-2018> is a problem that > worries not only Drill. > For example, recently was logged CALCITE-2538 > <https://issues.apache.org/jira/browse/CALCITE-2538> with the same bug. > > Kind regards, > Volodymyr Vysotskyi > >

Re: Publish Drill Calcite project artifacts to Apache maven repository

t;https://issues.apache.org/jira/browse/CALCITE-2087>, >> CALCITE-2018 <https://issues.apache.org/jira/browse/CALCITE-2018> and >> CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>. >> >> Kind regards, >> Volodymyr Vysotskyi >> >>

Re: Publish Drill Calcite project artifacts to Apache maven repository

rg/jira/browse/CALCITE-2018> and > CALCITE-1178 <https://issues.apache.org/jira/browse/CALCITE-1178>. > > Kind regards, > Volodymyr Vysotskyi > > > On Wed, Sep 12, 2018 at 7:39 PM Julian Hyde wrote: > >> I can confirm what Josh says about OSSRH. You need to fill out a f

Re: Publish Drill Calcite project artifacts to Apache maven repository

I can confirm what Josh says about OSSRH. You need to fill out a form with Sonatype that convinces them that you own the groupId (basically a domain name). Then they give you authorization to publish artifacts under that groupId. For example, I publish artifacts under the sqlline and

Re: How to get org.apache.calcite of calcite for drill

Does the Drill web site describe where to find the Calcite fork? I strongly believe that it should. Julian > On Feb 24, 2018, at 10:18 AM, Gautam Parai wrote: > > Drill uses its own fork of Calcite. You could open a JIRA in Apache Calcite > and commit the changes, then port

Re: LATERAL and UNNEST support for Drill

tting in Calcite would > need to be customized..currently we use DEFAULT. > > Overall, seems the advantages of CROSS/OUTER APPLY outweigh the > disadvantages, so we could go with that. > > > -Aman > > > > > On Tue, Jan 30, 2018 at 4:42 PM, Julian Hyde <jh...@ap

Re: LATERAL and UNNEST support for Drill

se between > using APPLY or overloading the meaning of LATERAL as in the current document > attached in the JIRA. Which way you think is the better way? > > > Thanks, > > Chunhui > > > From: Julian Hyde <jh...@apache.org> > Sent:

Re: LATERAL and UNNEST support for Drill

LATERAL is a prefix operator not a binary operator, so I believe you are missing a comma: > FROM t1 LATERAL UNNEST (t1.array1), UNNEST (t1.array2) should be > FROM t1, LATERAL UNNEST (t1.array1), LATERAL UNNEST (t1.array2) I agree with your remarks about the extra power of putting UNNEST in

Re: Excessive review comments

I don’t know whether anything is broken. I believed that the GitHub “start a review” feature would cause all review comments to be sent in a single email. But now I think of it, I’m not sure I ever saw it working. I wonder whether Github-ASF integration is at fault. Whatever the reasons for

Re: Date Conversion Question

A question on StackOverflow asks how to do this using Oracle’s TO_TIMESTAMP function, and there is a solution[1]. So, I tried SELECT to_timestamp ('2017-08-10T09:12:26.000Z', '-MM-DD"T"HH24:MI:SS.FF3"Z"') FROM DUAL on http://rextester.com/l/oracle_online_compiler

Re: Checkstyle Unused Imports

The options Ted is thinking of are: -Dcheckstyle.skip -DskipTests Julian > On Sep 11, 2017, at 12:46 PM, Ted Dunning wrote: > > On Mon, Sep 11, 2017 at 6:53 PM, Paul Rogers wrote: > >> The check style improvements are good, they will likely save

Re: ClassCastException (DateString cannot be cast to TimestampString) in Drill

I think you’re running into https://issues.apache.org/jira/browse/CALCITE-1178 which was logged by a Drill committer a while ago but has not been fixed. Calcite is strongly typed internally. So if we are to allow ’aTimestamp > aDate’ then we

Re: Working on upgrade Drill Calcite version

+dev@calcite. Excellent work, Roman. Your changes to Calcite don’t seem to be very major, and I ran the test suite on your https://github.com/KulykRoman/incubator-calcite/commits/DrillCalcite1.13.0_rc1 branch and all the tests pass. So when you are ready, I think we can expedite getting

Re: [ANNOUNCE] New PMC member: Arina Ielchiieva

Welcome! Well deserved. > On Aug 2, 2017, at 11:34 AM, rahul challapalli > wrote: > > Congratulations Arina! > > On Wed, Aug 2, 2017 at 11:27 AM, Kunal Khatua wrote: > >> Congratulations, Arina!! >> >> >> Thank you for your contributions to

Re: Drill query planning error

ful for this. Thanks for >>> pointing that out. I'll see if we can leverage that. The grouping sets >>> is not yet supported in Drill, but that would be a better solution since >> it >>> avoids extra scans. >>> >>> -Aman >>> >>> O

Re: Drill query planning error

Aman, Thanks for moving dev@calcite to Bcc. This is properly a Drill question. A blanket restriction on cartesian joins is a blunt instrument. Sometimes cartesian joins are valid, safe, and the best plan for a query. This is a case in point. Users shouldn’t have to change config parameters to

Re: Why Drill required a special Calcite fork ?

Leaving aside the fact that Drill needs a fork of Calcite (I accept the arguments for that, more or less), it’s embarrassing that the fork is poorly documented, poorly named (Calcite has been out of the incubator for almost 2 years, and hasn’t been called Optiq for each longer), and is in a

Re: Why rules from all plugins contribute into optimizing any type of query ?

What Ted said. But also, conversely, you should know that in Calcite you can write a general-purpose rule. Or better, re-use a general-purpose rule that someone else has written. There are logical rules, for example constant reduction and logic simplification, that work regardless of the data

LinkedIn requests

A few people (you know who you are!) have been sending LinkedIn requests to dev@drill. Please don’t send LinkedIn requests to dev or any other mailing list. As a list moderator I reject the requests, and a few days later LinkedIn re-sends the email and I have to moderate it again. If you know

Re: [ANNOUNCE] New PMC Chair of Apache Drill

Congratulations! On Fri, Jun 23, 2017 at 5:00 PM, Aman Sinha wrote: > Thank you all ! > > -Aman > > On Fri, Jun 23, 2017 at 3:59 PM, Paul Rogers wrote: > >> Congratulations Aman! >> >> And, thanks much to Parth, our outgoing chair, for his contributions

Re: Thinking about Drill 2.0

Avatica? > On Jun 15, 2017, at 10:39 AM, Paul Rogers wrote: > > Hi Uwe, > > This is incredibly helpful information! You explanation makes perfect sense. > > We work quite a bit with ODBC and JDBC: two interfaces that are very much > synchronous and row-based. There are

Re: Drill Summit/Conference Proposal

succeed at the above goals, thus I’m not certain what the right choice is, > but I wanted to bring up the point for discussion. > > > On June 14, 2017 at 2:32:45 PM, Julian Hyde (jh...@apache.org > <mailto:jh...@apache.org>) wrote: > >> I like the idea of co

Re: Drill Summit/Conference Proposal

I like the idea of co-hosting a conference. ApacheCon in particular is a good venue, and they explicitly encourage sub-conferences (there are “Big Data” and “IoT” tracks, and this year there were sub-conferences for Tomcat and CloudStack). DrillCon was part of ApacheCon, people could attend a

Re: [ANNOUNCE] New Committer: Charles Givre

Congratulations, Charles, and welcome! Thank you, not only for your code contributions, but also for your your work promoting Drill by writing and speaking at conferences. A simple search[1] turns up a lot of material. Julian [1] https://www.google.com/search?q=charles+givre+apache+drill >

Re: Thinking about Drill 2.0

> On Jun 5, 2017, at 11:59 AM, Paul Rogers wrote: > > Similarly, the storage plugin API exposes details of Calcite (which seems to > evolve with each new version), exposes value vector implementations, and so > on. A cleaner, simpler, more isolated API will allow storage

Re: Why isn't Drill using a more recent version of Calcite ?

It's not exactly true that "calcite came from drill". Calcite was originally called Optiq. Drill was the second project to use Optiq (Cascading was the first) and Optiq was a pretty significant code base (almost 200k lines of code) when Drill started to use it. Drill created their own branch/fork

Re: Issues categorization suggestion

In Calcite we assign a "newbie" flag to some issues. A more detailed categorization takes significant effort for the person triaging the bugs, so isn't worth it. On Thu, May 25, 2017 at 9:23 AM, Paul Rogers wrote: > Great suggestion. > > What I’ve learned over the last year,

Re: Understanding the science and concepts behind Calcite

Adding dev@drill to the cc list, because Muhammad also asked the question there. But please reply to dev@calcite only. I gave a talk “Why you should care about relational algebra”[1], intended for an audience of people who know SQL, but with a lot of details about algebra and algebraic

Re: Drill date & time types encoding

g> wrote: > > On Thu, Mar 16, 2017 at 4:41 PM, Julian Hyde <jh...@apache.org > <mailto:jh...@apache.org>> wrote: >> >>> On Mar 16, 2017, at 4:25 PM, Jinfeng Ni <j...@apache.org> wrote: >>> >>> Time/Timestamp without t/z should be

Re: Drill date & time types encoding

> On Mar 16, 2017, at 4:25 PM, Jinfeng Ni wrote: > > Time/Timestamp without t/z should be interpreted as local time. No. If I am in pacific time and I have a TIMESTAMP value “1970-01-01 12:00:00” and I send it to you in central european time you receive a TIMESTAMP value

Re: Drill date & time types encoding

I don’t think 4713 BC comes from the SQL standard. That is a Postgres thing. I believe that the standard says you should support timestamp precision up to 9 (i.e. nanoseconds). 2 ^ 64 nanoseconds is 584 years. So, it’s not possible to cram all of the timestamp values we’d like into a 64 bit

Re: [ANNOUNCE] New Committer: Arina Ielchiieva

Congratulations, and welcome! On Fri, Feb 24, 2017 at 9:17 AM, Abhishek Girish wrote: > Congratulations Arina! > > On Fri, Feb 24, 2017 at 9:06 AM, Sudheesh Katkam > wrote: > >> The Project Management Committee (PMC) for Apache Drill has invited Arina >>

Time zone

Can someone please clarify the timezone behavior of Drill’s TIMESTAMP data type. According to the SQL standard, there is no timezone stored in a TIMESTAMP value, nor is there an implicit time zone (such as UTC or the server or session’s time zone). Under the standard model, TIMESTAMP

Re: NPE when connecting to sqlline using username and password

reated an issue to track this - > https://github.com/julianhyde/sqlline/issues/55 > > > Regards, > Khurram > ____ > From: Julian Hyde <jh...@apache.org> > Sent: Thursday, February 9, 2017 1:28:28 AM > To: dev@drill.apache.org >

Re: NPE when connecting to sqlline using username and password

Agreed, you should use ’-n’. But also, please log a bug at https://github.com/julianhyde/sqlline . sqlline should give an error message, not throw a NullPointerException. Julian > On Feb 8, 2017, at 10:57 AM, Andries Engelbrecht

Re: Drill: Memory Spilling for the Hash Aggregate Operator

gt; > DrillSpillmemoryforHashAggregation.pdf<https://drive.google.com/file/d/0ByUg32jfEW16ajNiQlVRczhPTjA/view?usp=sharing> > drive.google.com > > > >-- Boaz > > > From: Julian Hyde <jh...@apache.org> > Sent: Friday, January 13

Re: Drill: Memory Spilling for the Hash Aggregate Operator

The attachment didn’t come through. I’m hoping that you settled on a “hybrid” hash algorithm that can write to disk, or write to memory, and the cost of discovering that is wrong is not too great. With Goetz Graefe’s hybrid hash join (which can be easily adapted to hybrid hash aggregate) if the

Re: Invoking UDF that doesn't have parameters without paranthesis

lob/master/exec/java-exec/src/main/codegen/includes/parserImpls.ftl > > <https://github.com/apache/drill/blob/master/exec/java-exec/src/main/codegen/includes/parserImpls.ftl> > > Thank you, > Sudheesh > >> On Dec 19, 2016, at 3:00 PM, Nagarajan Chinnasamy >> <nagaraja

Re: Invoking UDF that doesn't have parameters without paranthesis

I don’t know about Drill, but in Calcite you declare the function (SqlOperator) such that the getSyntax() method returns SqlSyntax.FUNCTION_ID. SqlCurrentDateFunction (CURRENT_DATE) is an example of this. > On Dec 19, 2016, at 12:00 AM, Nagarajan Chinnasamy >

Drill-Arrow integration

Can we please talk about what we want for Drill-Arrow integration? There was a patch several months ago[1] and it just got stuck. Julian [1] https://issues.apache.org/jira/browse/DRILL-4455

Re: [PROPOSAL] Apache Jira Workflow for Code Reviews

I like 2 also. Is the following variant of 2 possible in JIRA? Make the "ready to commit" flag into a status. Thus status changes from "open" to "in progress" to "reviewable" to "ready to commit" (or "approved"). The inability to search by assignee should not be a huge problem - it is in the

Re: About the IN condition push down.

I’m not sure what you mean by “notified about the IN condition”. You either have to convert it to a semi-join or not. I don’t know how expensive hash-joins are in Drill. If they’re expensive, you could hand-write a UDF that builds a java hash-map, and see whether it performs better. Julian

Re: Query JSON that has null as value for each key

IMHO it is similar but not the same as DRILL-1256. Worth logging an issue and let Jacques (or someone) put on the record what should be the behavior of an empty record (empty JSON map) when it is top-level (as in this case) or in a collection. Julian > On Nov 10, 2016, at 9:12 AM, rahul

Re: dynamodb storage plugin

Forwarding to Calcite dev. I have heard that people are working on a Calcite adapter for DynamoDB and Calcite adapters can often be used in Drill. Julian > On Sep 4, 2016, at 12:03 PM, Navin Viswanath wrote: > > Hi, > > I'm currently working on a tool that provides a

Re: The project says it has dozens of committers

On Drill's Team page[1] it says “It currently includes dozens of contributors employed by many organizations”. It doesn’t make any claim about number of *committers*, only *contributors*. I think you mis-read the page. I count 99 distinct email addresses and 88 distinct names in the commit log,

Re: Proposed August report for Drill

+1 The report looks good. Just curious: the dev and issues lists show about a 40% drop off compared to last quarter. Any idea why? Julian > On Aug 3, 2016, at 11:20 PM, Parth Chandra wrote: > > Below is the proposed report for the August board meeting. Please

Re: Dynamic UDFs support

But don't call it DELETE. In SQL the opposite of CREATE is DROP. Julian > On Jul 25, 2016, at 8:48 AM, Keys Botzum wrote: > > I like the approach to handling DELETE. This is very useful. I think an > implementation that does not guarantee consistent behavior is

Re: A light-weight, versioned client API for Drill

t; driver. To be honest, I was a bit concerned about the overhead of converting > rows to/from JSON. Have you looked at fitting a binary protocol under > Avatica? Would sure be great to reuse the work already done to handle the > many JDBC complexities. > > - Paul > >>

Re: A light-weight, versioned client API for Drill

Did you consider Avatica? Identical goals, it works already, and there are clients in several languages. Julian On Wed, Jul 20, 2016 at 10:35 AM, Chunhui Shi wrote: > Cool. And we know that there are already many 'light weight' APIs soon > become the main stream APIs. > > On

Re: Implement "DROP TABLE IIF EXISTS" statement

Even though it’s not standard, several other databases have DROP TABLE … IF EXISTS (MySQL [1]; Postgres [2] and SQL Server 2016 [3] put the “IF EXISTS” before the table name). I know there are problems with the IF keyword clashing with the Hive “IF” function, but I think it would be crazy to do

Re: median, quantile

I’ve thought for some time that SQL aggregate functions should have an “APPROXIMATE ( … )” clause. Users don’t WANT to call a TD_MEDIAN function, they want the MEDIAN that gives them an answer to their desired accuracy (within X, within Y%, or within a given confidence interval), and TD_MEDIAN

Re: Probabilistic data structures in Drill

Drill also makes use of hash tables and hash partitioning. I’m not sure what was the purpose of your question. Are you carrying out a survey? Julian > On May 1, 2016, at 5:22 PM, Ted Dunning wrote: > > Drill doesn't use any such data structures in itself. The emphasis

Re: Issue with IN Clause while reading data

Attachments don’t come through the apache email system too well. Probably best that you log a JIRA case, and attach any files needed for a test case. Of course the more minimal the test case, the better. Julian > On Apr 28, 2016, at 11:00 PM, nitin.a.sar...@accenture.com wrote: > > Hi, > >

Re: [jira] [Created] (DRILL-4638) Netflix support

This is part of the spam storm that has been sweeping many Apache projects’ JIRA accounts over the past few days. Julian > On Apr 23, 2016, at 4:50 PM, Edmon Begoli wrote: > > How in the world did this sneak into the JIRA? > > Are we going to get next an email from

Re: Getting back on Calcite master: only a few steps left

tests for CALCITE-1150 going? Can Minji help get together >> test cases for CALCITE-1150? Maybe you could provide guidance on the set of >> queries to test? >> >> thanks, >> Jacques >> >> >> -- >> Jacques Nadeau >> CTO and Co-Founder, Dr

Re: Continued Avro Frustration

Stefan, I wanted to chime in. I don’t think Jacques was out of line. I understand your frustration, but the project does not owe you anything. The only surefire way to get a feature into the project is to contribute it yourself AND to work through the process of getting it accepted. If you

Re: [DISCUSS] Remove required type

Jacques, Doesn't Drill detect the type of each column within each batch? If so, does it (or could it) also detect that a particular column is not null (again, within the batch)? You may not generate not-null data, but a lot of data is not-null. Let's not be too hasty to dismiss this as a

Re: Optimizing SUM(1) query

Is there any reason why Drill cannot transform SUM(1) to COUNT(*) at an early stage (i.e. using a logical optimization rule) so that this optimization does not need to be done for each engine? > On Mar 15, 2016, at 5:29 AM, Sudip Mukherjee wrote: > > I was trying to

Re: hive translate function is not working from Drill

Arina: I did reply to your message on dev@calcite. See http://mail-archives.apache.org/mod_mbox/calcite-dev/201602.mbox/%3CDB1F2B6D-C23A-45E7-B400-C7458DCD9CF1%40apache.org%3E

Re: Optimizing SUM(1) query

PS I did recall correctly: https://issues.apache.org/jira/browse/HIVE-6192. But it's not implemented using Calcite, sadly. On Fri, Feb 19, 2016 at 12:11 PM, Julian Hyde <jh...@apache.org> wrote: > And indeed COUNT(*) is equivalent to COUNT(1). COUNT(*) is the same as > COUNT(e) wh

Re: Optimizing SUM(1) query

And indeed COUNT(*) is equivalent to COUNT(1). COUNT(*) is the same as COUNT(e) where e is any not-null value. I would argue that SUM(1) should be optimized to COUNT(*). Or, generalizing a bit, that SUM(c) should be optimized to COUNT(*) * c. IIRC, Hive performs that optimization. It's a bit

Re: Deterministic behavior of Negative Function?

I don’t recall interval literals being discussed on the Calcite list. We do support interval literals of the standard types (day-to-second or year-to-month) but we don’t support interval literals (or interval values) of month-to-day type. I think there’s a good reason that that kind of literal

Re: Naming the new ValueVector Initiative

To expand on what “straight to TLP” means (correct me if I’m wrong, Jacques). From an IP standpoint, the new project is a clone of Drill. It starts off with Drill’s code base. We then, as the sculptor said [1], chip away everything that doesn’t look like Arrow. Julian [1]

Re: Naming the new ValueVector Initiative

>> >>>> wrote: >>>>> >>>>> Just added my vote. >>>>> >>>>> On Thu, Dec 3, 2015 at 12:51 PM, Wes McKinney <w...@cloudera.com >>>>> <mailto:w...@cloudera.com>> wrote: >>>>>> Shall we

Re: Can we pass the #skipped records with RecordBatch?

+1 for a sideband mechanism. Sideband can also allow correlated restart of sub-queries. In sideband use cases you described, the messages ran in the opposite direction to the data. Would the sideband also run in the same direction as the data? If so it could carry warnings, rejected rows,

Re: Naming the new ValueVector Initiative

missed this for a few days last week with holiday travel. >> >> On Thu, Nov 26, 2015 at 3:04 PM, Julian Hyde <jul...@hydromatic.net> >> wrote: >> >>> Consulting a lawyer is part of the Apache branding process but the first >>> stage is

Re: Naming the new ValueVector Initiative

est we take name suggestions for step 1 from everyone but then > constrain the voting to the newly proposed project [1]. We could just do > this in a private email thread but I think doing it on Drill dev is better > in the interest of transparency. This isn't the perfect place for that but &g

Re: Announcing new committer: Ellen Friedman

Congratulations, Ellen! Thanks for all you’ve done for Drill so far. Julian > On Nov 22, 2015, at 5:50 PM, Worthy LaFollette wrote: > > Congrats, Welcome! > > On Sun, Nov 22, 2015 at 6:38 PM, Jacques Nadeau wrote: > >> The Apache Drill PMC is very

Re: Moving directory based pruning to fire earlier

ogical Plan, Physical >> Plan). >> >> So, for now, we do have to override/exend all DrillLogicalRel. >> >> >> On Mon, Nov 23, 2015 at 4:55 PM, Julian Hyde <jh...@apache.org> wrote: >>> I’m not sure what properties / behavior you want

Re: Moving directory based pruning to fire earlier

I’m not sure what properties / behavior you want to override but remember that Calcite specifies a lot of brings as traits or metadata. For example, “double RelNode.getRows()" is deprecated and you would these days use RelMetadataQuery.getRowCount(). You would not need to sub-class a RelNode

Re: Moving directory based pruning to fire earlier

But it's still up to each Rel node to > decide how to estimate it's own cost, given the row count, distinct > row count etc from MetadataProvider. Are you suggesting we completely > remove the Drill's costing estimation method, and use Calcite's > default one? > > >

Drill on JDK 1.8

What’s the state of Drill on JDK 1.8? https://issues.apache.org/jira/browse/DRILL-1491 has been open for over a year, and doesn’t describe what the remaining issues are. Julian

Re: Drill on JDK 1.8

H tests + TPCDS tests and performance tests using > Drill and JDK8. > > On Thu, Nov 19, 2015 at 4:35 PM, Julian Hyde <jh...@apache.org> wrote: > >> What’s the state of Drill on JDK 1.8? >> https://issues.apache.org/jira/browse/DRILL-1491 < >> https://issu

Re: [DISCUSS] Get off Calcite Forked Version

other implementations of the >> operators (e.g. Calcite, Phoenix) going to implement the operator now >> that Drill's lax validation policy has allowed it in? >> >> [ Will discuss in Calcite list once we have the PR ready for this patch. >> ] >> >> 9. I

Re: [DISCUSS] Get off Calcite Forked Version

t; our burn down hasn't been super successful. And sometimes I feel like > Jinfeng gets stuck doing all the heavy lifting. > > -- > Jacques Nadeau > CTO and Co-Founder, Dremio > >> On Tue, Nov 17, 2015 at 9:48 AM, Julian Hyde <jhyde.apa...@gmail.com> wrote: &

[jira] [Created] (DRILL-4107) Broken links in web site

Julian Hyde created DRILL-4107: -- Summary: Broken links in web site Key: DRILL-4107 URL: https://issues.apache.org/jira/browse/DRILL-4107 Project: Apache Drill Issue Type: Bug

Re: Proposal for Skipping Records

It would be useful if you could describe the different ways that a record can be “bad”. IIRC the SQL standard divides the conditions into errors and warnings. Examples of a warning would be a string column that is truncated because it is too large for a varchar(20), or numeric underflow when

Re: Proposal for Skipping Records

t beliefs on the definition. However, > from the aspect of users' experience, they could just proceed and see the > different types of errors at the log, which helps them judge whether the > failure is tolerable or not. > > On Mon, Nov 16, 2015 at 11:56 AM, Julian Hyde <jh...@apache.org&

Re: select from table with options

. > > On Thu, Nov 12, 2015 at 8:34 PM, Julian Hyde <jh...@apache.org> wrote: > >> You’re hitting the grammar ambiguity I expected. >> >> I think that base Calcite should require the full verbose syntax: the >> TABLE keyword for table functions and the EXTEND key

Re: select from table with options

to call table functions > - allow using table functions and extend together. > Does it make sense? > Julien > > > On Tue, Nov 10, 2015 at 12:51 PM, Julian Hyde <jh...@apache.org> wrote: > >> To be clear, it should be possible to use a table function with all of >&

Re: select from table with options

acques Nadeau <jacq...@dremio.com> >> wrote: >>> >>>> My proposal was an a or b using the freemarker template in the grammar, >>>> not something later. >>>> >>>> Actually, put another way: we may want to consider stating that we

Re: select from table with options

, 2015 at 12:28 PM, Julien Le Dem <jul...@dremio.com> wrote: > In the patch I just sent, probably not. > I will adjust it and add the corresponding test. > > On Tue, Nov 10, 2015 at 11:51 AM, Julian Hyde <jh...@apache.org> wrote: > >> Can you use both together? Say >

Re: select from table with options

ytable` (type => 'CSV', fieldDelimiter >> => '|', skipFirstRow => true)) >> >> It also looks much more like a hint to the table (which is our goal). >> >> >> >> >> >> >> >> -- >> Jacques Nadeau >> CTO and

Re: select from table with options

hen using named parameter. We do want to > overload in this case, which is why I'm looking into it. > > I'll fill a JIRA for my other branch > > Julien > > On Thu, Nov 5, 2015 at 5:39 PM, Julian Hyde <jh...@apache.org> wrote: > >> >> On Nov 5, 2015

Re: Temporary branches

nt to > propose on that other thread so I can +1? > > -- > Jacques Nadeau > CTO and Co-Founder, Dremio > > On Thu, Nov 5, 2015 at 1:28 PM, Julian Hyde <jh...@apache.org> wrote: > >> >>> On Nov 5, 2015, at 1:12 PM, Jacques Nadeau <jacq...@dremi

Re: select from table with options

> On Nov 5, 2015, at 5:00 PM, Julien Le Dem wrote: > > TL;DR: TableMacro works for me; I need help with a bug in Calcite when > there's more than 1 function with the same name. Yes; see below. > FYI: I have a prototype of TableMacro working in Drill. For now just being >

Re: select from table with options

On Sun, Oct 25, 2015 at 10:13 PM, Jacques Nadeau wrote: > Agreed. We need both select with option and .drill (by etl process or by > sql ascribe metadata). > > Let's start with the select with options. My only goal would be to make > sure that creation of .drill file through

Re: Drill hangout conflict with Calcite hangout..

I didn’t realize I had scheduled the Calcite hangout at the same time as the Drill hangout. Sorry! And thanks for flexing with this, Drillers. Here’s a virtual slice of Calcite’s graduation cake, if it’s any consolation… https://twitter.com/ApacheCalcite/status/659072259164803072

Re: Drill 1.3 Timing: Let's start the vote next week

Sounds good to me. On a related note, Calcite’s 1.5 release. That release has slipped about a week, so there might be time to get https://issues.apache.org/jira/browse/CALCITE-911 in, which I know is important to Drill. Ironically if Drill

Re: [DISCUSS] Proposal to turn ValueVectors into separate reusable library & project

+100 Thanks for spearheading this, Jacques. They say memory is the new disk. So, it’s no longer sufficient to use the same on-disk data format if we want our tools to interoperate. The idea of engines interoperating by reading the same in-memory temporary tables, and passing data from one

Re: [DISCUSS] Design Documents

Zelaine, Welcome to the Drill community! It was great working with you a few years ago (I think some of your contributions are still present in the code base that evolved into Calcite) and look forward to working together again. Julian

Re: select from table with options

Whatever API is used to scan files from SQL, there will need to be a corresponding way to accomplish the same thing in a user interface. Probably a form with various fields, some of them with drop-boxes etc. And ideally a facility that samples a few hundred rows to deduce the probable field names

Re: select from table with options

+1 to use table functions In Calcite (and I presume Drill) a “table function” may actually function more like a (Lisp) macro. The function gets called at prepare time to yield a RelNode (say a TableScan). So a table function is every bit as efficient as using a table, but it allows extra

Re: Apache Drill

ed down far enough (to the >>> parser) >>>> to not make a noticeable difference (which is what I think Julian is >>>> implying)? >>>> >>>> Sent from my iPhone >>>> >>>>> On Oct 17, 2015, at 1:41 PM, Magnus Pierre

Re: Apache Drill

Seems to me the biggest problem is to make drill understand the nested structure of an xml document. That work has been done for json, so let's build on it. Suppose there was a translator that converted xml to json (adding attributes for things that json lacks, such as namespaces, text, element

Re: Apache Drill

that >> is able to deal with decently complex xml's, that I currently use in Storm. >> Takes attributes, and everything. >> >> I can share it with the community if interesting. >> >> /Magnus >> Den 17 okt 2015 7:02 em skrev "Julian Hyde" <jul...@h

  1   2   >