Re: Topic suggestions for April Tech Talk

2021-03-19 Thread la...@apache.org
An interesting topic would BigData ecosystem integration, which is clearly one 
of the strengths of Phoenix.

I.e. with Trino (formerly Presto), Spark, and classical MapReduce. Perhaps this 
could cover also HBase snapshot support.

I'm happy to cover this. But I can't to that for April 1st - juggling too many 
things right now.

-- Lars

On Tuesday, March 9, 2021, 10:54:16 AM PST, Kadir Ozdemir 
 wrote: 





Hi All,

This is a friendly reminder that our next tech talk meeting will be held at
9AM PST on April 01. If you like to present a topic for the next meeting,
please let us know by March 18. For more information about our tech talks,
and the slides and recording for the previous presentation, please visit
https://phoenix.apache.org/tech_talks.html.

I look forward to your suggestions for the next meeting.

Thanks,
Kadir


Re: [DISCUSS] Unbundling Sqlline and slf4j backend from phoenix-client and phoenix-client embedded

2021-05-26 Thread la...@apache.org
Will sqlline still be part of the Phoenix "distribution"? Or will it become a 
separate package to install?






On Wednesday, May 26, 2021, 1:07:17 AM PDT, Istvan Toth  
wrote: 





Hi!

The current purpose of the phoenix-client JAR is twofold:
- It servers as a generic JDBC driver for embedding in applications
- It also contains the sqlline library used by the sqlline.py script, as
well as the slf4j log4j backend.
- (It also contains a some Phoenix code and HBase libraries not necessary
for a client, but we're already tracking that in different tickets)

One major pain point is the slf4j backend, which makes phoenix-client
incompatible with applications and libraries that do not use log4j 1.2 as a
backend, and kind of defeats the purpose of using slf4j in the first place.
phoenix-client-embedded solves this problem by removing the slf4j backend
from Phoenix.

In PHOENIX-6378  we aim
to remove sqlline from the phoenix-client JAR, as it further cleans up the
classpath, and avoids locking phoenix to the sqlline version that it was
built with.

In Richard's current patch, we remove sqlline from phoenix-client-embedded,
and use that in the sqlline script.

In our quest for a more useable phoenix-client, we can do two things now:

  1. Remove both the slf4j backend, and sqlline from phoenix-client, and
  also drop phoenix-client-embedded as it would be the same as phoenix-client
  2. Remove sqlline from phoenix-client-embedded, and keep the current
  phoenix-client as backwards compatibility option

I'd prefer the first option, but this is somewhat more disruptive than the
other.

Please share your thoughts. Do you prefer option 1, 2, or something else
entirely ?

Istvan