drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Gilmore <a...@pharmadata.net.au>
Subject Re: Storage Plugin Config for XML
Date Mon, 02 Mar 2015 07:27:24 GMT
I would imagine you'd have to read all XML as a string unless an XSD was
provided, which would allow you to infer the types.  Still be easy enough
to cast to the types you need, similar to JSON in the all text mode.


*Adam Gilmore*

Director of Technology


+61 421 997 655 (Mobile)

1300 733 876 (AU)

+617 3171 9902 (Intl)


Data Intelligence Solutions for Pharmacy

www.PharmaData.net.au <http://www.pharmadata.net.au/>

[image: pharmadata-sig]


This communication including any attachments may contain information that
is either confidential or otherwise protected from disclosure and is
intended solely for the use of the intended recipient. If you are not the
intended recipient please immediately notify the sender by e-mail and
delete the original transmission and its contents. Any unauthorised use,
dissemination, forwarding, printing, or copying of this communication
including any file attachments is prohibited. The recipient should check
this email and any attachments for viruses and other defects. The Company
disclaims any liability for loss or damage arising in any way from this
communication including any file attachments.

On Wed, Feb 25, 2015 at 5:41 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> To help with this, I just added some pretty ratty capability to log-synth
> to generate XML data.
> You might try generating some data for the customer and then they can
> point and say "more like this" and "less like that".
> This will give you pretty realistic sample data without security issues.
> On Wed, Feb 25, 2015 at 5:28 AM, Chad Smykay <csmykay@mapr.com> wrote:
>> I have a customer that will be using Drill in production for an ETL
>> engine use case.  I will try and get example data but the customer they are
>> supporting is EXTREMELY sensitive in sharing any data, even sample data.
>> If I can find out what schema's they plan on using it would be a could
>> initial use case.  Thanks for the responses.
>> --
>> Kind Regards,
>> Chad Smykay  |  Solutions Architect  |  M: 210.273.2344
>>   mapr.com <http://www.mapr.com>
>> Jacques Nadeau wrote:
>> Not yet.  That being said, I think someone could make something pretty
>> quick since there is an XML extension for Jackson that would plug nicely in
>> next to our current json reader.
>> On Mon, Feb 23, 2015 at 10:53 AM, Chad Smykay <csmykay@mapr.com> wrote:
>>> Here is why I ask:
>>> https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+Contribution+Ideas
>>> States:
>>> Support for new file format readers/writers
>>> Currently Drill supports text, JSON and Parquet file formats natively
>>> when interacting with file system. More readers/writers can be introduced
>>> by implementing custom storage plugins. Example formats include below.
>>> AVRO
>>> Sequence
>>> RC
>>> ORC
>>> Protobuf
>>> XML
>>> Thrift
>>> ....
>>> The word here being "custom storage plugins"  So I thought maybe someone
>>> has already taken a crack and setting one up before I try.
>>> --
>>> Kind Regards,
>>> Chad Smykay  |  Solutions Architect  |  M: 210.273.2344
>>>   mapr.com <http://www.mapr.com>
>>> Jahagirdar, Madhu wrote:
>>>  I am also interested in the storage plugin for XML.
>>>   From: Chad Smykay
>>> Reply-To: "user@drill.apache.org", "csmykay@mapr.com"
>>> Date: Tuesday, 24 February 2015 12:19 am
>>> To: "user@drill.apache.org"
>>> Subject: Storage Plugin Config for XML
>>>   Does anyone know of a working config for XML based files and
>>> extensions?
>>> --
>>> Kind Regards,
>>> Chad Smykay  |  Solutions Architect  |  M: 210.273.2344
>>>   mapr.com <http://www.mapr.com>
>>> ------------------------------
>>> The information contained in this message may be confidential and
>>> legally protected under applicable law. The message is intended solely for
>>> the addressee(s). If you are not the intended recipient, you are hereby
>>> notified that any use, forwarding, dissemination, or reproduction of this
>>> message is strictly prohibited and may be unlawful. If you are not the
>>> intended recipient, please contact the sender by return e-mail and destroy
>>> all copies of the original message.

  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message