Hi,
As we write code for Trafodion, some of it might be useful for others in
the community, without fitting into the Trafodion source tree. For example,
a scalar UDF to perform certain things, a table-mapping UDF to read from
some data source, or a "recipe" to install Trafodion in a certain
enviro
+1, especially with the syntax that allows to override the error.
Hans
On Fri, Jan 22, 2016 at 9:11 AM, Qifan Chen wrote:
> Hi Dave,
>
> Sounds like a good idea, at least for now.
>
> We may also need to define how big is too big, maybe through a CQD.
>
> --Qifan
>
> On Fri, Jan 22, 2016 at 10:
Hi,
That decision would be made by Hive, not Trafodion. For people who use
install_local_hadoop, we recently changed that setup to use local
MapReduce, not YARN, see
https://issues.apache.org/jira/browse/TRAFODION-1781.
Hans
On Tue, Feb 2, 2016 at 12:58 PM, Gunnar Tapper
wrote:
> Hi Suresh:
>
pReduce to sort the data during table population,
>> after disabling YARN. This is observed on a workstation.
>>
>> Thanks -Qifan
>>
>> On Tue, Feb 2, 2016 at 3:12 PM, Hans Zeller
>> wrote:
>>
>>> Hi,
>>>
>>> That decision would be
No, it is not required in the build environment.
Hans
On Tue, Feb 2, 2016 at 1:54 PM, Gunnar Tapper
wrote:
> Does this mean that MRv1 is now required in the build environment?
>
> On Tue, Feb 2, 2016 at 2:12 PM, Hans Zeller wrote:
>
>> Hi,
>>
>> That decis
+1 for the dragon as well. We used to have an informal logo with another
somewhat cursive font, it shows in one of the carousel pictures on the
trafodion.apache.org site. That might be better (although still not my
favorite).
Hans
On Tue, Feb 9, 2016 at 11:52 AM, Ken Holt wrote:
> By the way, t
Hi Gunnar, sounds good to me. Two somewhat related comments: One is that if
Trafodion uses a floating IP address in a cloud deployment, like Amazon
AWS, the trafodion id will need limited sudo capabilities to move the
elastic IP address from one node to another.
The other is what we should not do:
; On Tue, Feb 9, 2016 at 4:03 PM, Sandhya Sundaresan <
> sandhya.sundare...@esgyn.com> wrote:
>
> I’d say there is enough “curliness” going on with the dragon. So we could
> try with a simple bold font . Perhaps with an outline of a different color
> like Hado
id, either one is fine.
>
>
>
> Dave
>
>
>
> *From:* Eric Owhadi [mailto:eric.owh...@esgyn.com]
> *Sent:* Thursday, February 11, 2016 3:02 PM
> *To:* user@trafodion.incubator.apache.org
> *Subject:* RE: Logo Proposal
>
>
>
> +1 option 4
>
>
>
&
+1 for 13
Hans
On Thu, Feb 18, 2016 at 6:23 PM, Gunnar Tapper
wrote:
> +1 for 13.
>
> On Thu, Feb 18, 2016 at 7:03 PM, Roberta Marton
> wrote:
>
>> +1 for 13
>>
>>
>>
>>Roberta
>>
>>
>>
>> *From:* Roberta Marton [mailto:roberta.mar...@esgyn.com]
>> *Sent:* Thursday, February 18, 2016 6:02
Hi,
Here is a question on how we should define the meaning of an UPSERT
statement. UPSERT is not part of the ISO/ANSI SQL standard, so we have some
leeway to define it.
My personal feeling is that UPSERT should either insert a brand-new row or
it should completely replace an existing row, but it
he row doesn’t exist, it’s just a
> straight insert (with defaults for omitted columns).
>
>
>
> And if one really wants UPDATE semantics as opposed to “replace”
> semantics, then the ANSI MERGE statement (which Trafodion also supports) is
> the way to go.
>
>
>
>
columns
>
> If we switch to insert all column values all the time for non-aligned
> format, then we can let user to control what value needs to be put in for
> the omitted column.
>
>
>
> Selva
>
>
>
> *From:* Hans Zeller [mailto:hans.zel...@esgyn.com]
> *Sent:* Tuesda
rid format rows where some columns are in aligned format and
> others
>
> are not.
>
>
>
> anoop
>
>
>
> *From:* Hans Zeller [mailto:hans.zel...@esgyn.com]
> *Sent:* Tuesday, March 15, 2016 5:58 PM
> *To:* user@trafodion.incubator.apache.org
> *Subject:* Re: Upsert seman
Hi Ming, I think the C data type corresponding to datetime values is
SQLUDR_CHAR. You create a string that looks like "2016-03-23 01:23:45"
(this example is for a TIMESTAMP(0)) and return that. Trafodion will
convert it to the datetime type.
Sorry, I have not tested it but hope it will work.
Hans
Hi,
We could probably remove OID as a reserved word. I don't think it is used
by Trafodion, but it might have been flagged in the ISO/ANSI standard as a
potential reserved word in the past. I don't see it as a reserved word int
he SQL99 standard. Most databases allow the use of reserved words as
i
Created TRAFODION-1939
<https://issues.apache.org/jira/browse/TRAFODION-1939> to track this
suggestion.
Hans
On Wed, Apr 13, 2016 at 9:07 AM, Hans Zeller wrote:
> Hi,
>
> We could probably remove OID as a reserved word. I don't think it is used
> by Trafodion, but it mig
Hi Dave,
Yes, the general model is to use C++ new and delete, and it is the UDR
writer's responsibility not to leak objects.
In more detail:
*The simple and easy model*
Don't allocate resources in the compile time interface. At runtime (in the
method that overrides UDR::processData()), allocate
Hi,
Here is a question on Hive data types. Ming is about to add support for
Hive VARCHAR data types, in addition to the existing STRING type, but we
hit a question we wanted to pose to the user community. Here is a proposed
type mapping from Hive to Trafodion:
Hive type Trafodion type Max # of ch
Yes, I agree with Suresh. The reason is likely that you defined the output
column name as a lower-case string "id", and that is treated as a
case-sensitive, delimited identifier. If you define the column as "ID" in
the UDF, that is treated as a regular identifier, which is not
case-sensitive. The c
Hi Ming,
One thing to test would be where you get the timeout, whether it's in JDBC
done in the SPJ or in the communication between the master executor and the
UDR server. When you simulate it in your dev environment, do you also issue
a single JDBC call that takes more than an hour?
I have to ad
Hi,
Another thing you can do is to specify the limit in the VARCHAR in bytes,
not in characters. If you can do that and if you normally store 1, 2 or 3
byte characters in the key, that could be more efficient. When specifying
the limit in characters, every UTF-8 character uses the maximum length o
Hi Kevin,
At this time, using the "default" connection is only supported for stored
procedures in Java, not for TMUDFs. I would recommend to just make a
regular JDBC (or ODBC, if you use C++) connection from the UDF. Just make
sure to close the connection, even in cases where an exception is throw
have:
>
> select save(id) from test where name=’b’;
>
> 2
>
> 2,5
>
> 2,5,6
>
>
>
>
>
> Best Regards,
>
> Kevin Xu
>
>
>
> *From:* Hans Zeller [mailto:hans.zel...@esgyn.com]
> *Sent:* Saturday, August 27, 2016 2:43 PM
> *To:* user@trafodio
Hi,
The method by Itzik Ben-Gan mentioned in the blog might not work exactly as
written, because it assumes that the result of a division by two is an integer,
which is not the case in Trafodion. You might need to add a cast to integer or
largeint to make it work.
Here is a query using WITH cl
Hi,
+1 on Dave's CQD solution. Also, it might be good if we just install snappy on
our workstations to avoid issues.
We already have other CQDs that follow this approach, for the default character
sets, default byte semantics, allowing nullable keys, Hive string length, etc..
I think that KISS
Hi,
The problem is how sqlci interprets its input data. In your case, sqlci
interprets the data as ISO8859-1, that makes the input 3*3 bytes or 9 ISO
8859-1 characters. It then translates those 9 (junk) characters into UTF-8,
requiring 18 bytes, and those don't fit into the target table. Once y
yn.cn<mailto:yuan@esgyn.cn>
Cellphone: (+86) 13671935540
From: Hans Zeller [mailto:hans.zel...@esgyn.com]
Sent: Wednesday, June 28, 2017 2:38 AM
To:
user@trafodion.incubator.apache.org<mailto:user@trafodion.incubator.apache.org>
Subject: RE: How many Chinese characters can be stored i
28 matches
Mail list logo
