You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@phoenix.apache.org by Istvan Toth <st...@apache.org> on 2021/05/26 08:06:50 UTC
[DISCUSS] Unbundling Sqlline and slf4j backend from phoenix-client
and phoenix-client embedded
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 <https://issues.apache.org/jira/browse/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
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by Istvan Toth <st...@cloudera.com.INVALID>.
Yes, based on Josh's comments we're currently planning to with #2
1. Remove sqlline et al from phoenix-client-embedded
2. Leave phoenix-client unchanged
3. Provide an uber sqlline jar, for use with sqlline.py. , and switch
sqlline.py to phoenix-client-embdedded
Istvan.
On Thu, May 27, 2021 at 9:19 PM larsh@apache.org <la...@apache.org> wrote:
> - User
>
> I see, make sense. So if I understand this correctly then:
>
> 1. Remove sqlline et al from phoenix-client
> 2. Remove phoenix-client embedded (since it is now the same as
> phoenix-client)
> 3. Provide an uber sqlline jar, for use with sqlline.py.
>
> i.e. option #1?
>
> PR 1239 seems to keep the phoenix-client jar, though. Which is option #2
> below.
>
> -- Lars
>
> On Wednesday, May 26, 2021, 9:36:30 PM PDT, Istvan Toth <
> stoty@cloudera.com> wrote:
>
>
>
>
>
> The technical details:
>
> The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with
> all of its own dependencies shaded in)
> in the /lib directory, along with the log4j slf4j backend jar.
> sqlline.py and friends is to be updated to add those to the classpath.
>
> Richard has this already up in https://github.com/apache/phoenix/pull/1239
>
> On Wed, May 26, 2021 at 9:43 PM Josh Elser <el...@apache.org> wrote:
> > I think the idea is that we would include a sqlline jar with the Phoenix
> > distribution. Context: we had some grief where a sqlline upgrade caused
> > user pain because they were relying on specific output from sqlline.
> >
> > If we have the sqlline jar _not_ packaged inside phoenix-client, then
> > users can easily replace the version of sqlline which makes them
> happiest.
> >
> > While I agree with Istvan that #1 is the more "correct" option, I'm
> > worried about the impact of folks who rely on the phoenix-client.jar to
> > be a "batteries included" fat-jar. Removing sqlline from
> > phoenix-client-embedded is great, so I'd lean towards #2.
> >
> > We can see what adoption of phoenix-client-embedded looks like now that
> > we have it in releases. I imagine most folks haven't yet realized that
> > it's even an option that's available.
> >
> > On 5/26/21 1:16 PM, larsh@apache.org wrote:
> >> 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 <
> stoty@apache.org> 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 <https://issues.apache.org/jira/browse/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
> >>
> >
>
>
> --
> István Tóth | Staff Software Engineer
>
> stoty@cloudera.com
>
>
> ________________________________
>
>
--
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
<https://www.cloudera.com/>
------------------------------
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by "larsh@apache.org" <la...@apache.org>.
- User
I see, make sense. So if I understand this correctly then:
1. Remove sqlline et al from phoenix-client
2. Remove phoenix-client embedded (since it is now the same as phoenix-client)
3. Provide an uber sqlline jar, for use with sqlline.py.
i.e. option #1?
PR 1239 seems to keep the phoenix-client jar, though. Which is option #2 below.
-- Lars
On Wednesday, May 26, 2021, 9:36:30 PM PDT, Istvan Toth <st...@cloudera.com> wrote:
The technical details:
The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with all of its own dependencies shaded in)
in the /lib directory, along with the log4j slf4j backend jar.
sqlline.py and friends is to be updated to add those to the classpath.
Richard has this already up in https://github.com/apache/phoenix/pull/1239
On Wed, May 26, 2021 at 9:43 PM Josh Elser <el...@apache.org> wrote:
> I think the idea is that we would include a sqlline jar with the Phoenix
> distribution. Context: we had some grief where a sqlline upgrade caused
> user pain because they were relying on specific output from sqlline.
>
> If we have the sqlline jar _not_ packaged inside phoenix-client, then
> users can easily replace the version of sqlline which makes them happiest.
>
> While I agree with Istvan that #1 is the more "correct" option, I'm
> worried about the impact of folks who rely on the phoenix-client.jar to
> be a "batteries included" fat-jar. Removing sqlline from
> phoenix-client-embedded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, larsh@apache.org wrote:
>> 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 <st...@apache.org> 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 <https://issues.apache.org/jira/browse/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
>>
>
--
István Tóth | Staff Software Engineer
stoty@cloudera.com
________________________________
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by Istvan Toth <st...@cloudera.com>.
The technical details:
The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with
all of its own dependencies shaded in)
in the /lib directory, along with the log4j slf4j backend jar.
sqlline.py and friends is to be updated to add those to the classpath.
Richard has this already up in https://github.com/apache/phoenix/pull/1239
On Wed, May 26, 2021 at 9:43 PM Josh Elser <el...@apache.org> wrote:
> I think the idea is that we would include a sqlline jar with the Phoenix
> distribution. Context: we had some grief where a sqlline upgrade caused
> user pain because they were relying on specific output from sqlline.
>
> If we have the sqlline jar _not_ packaged inside phoenix-client, then
> users can easily replace the version of sqlline which makes them happiest.
>
> While I agree with Istvan that #1 is the more "correct" option, I'm
> worried about the impact of folks who rely on the phoenix-client.jar to
> be a "batteries included" fat-jar. Removing sqlline from
> phoenix-client-embedded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, larsh@apache.org wrote:
> > 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 <
> stoty@apache.org> 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 <https://issues.apache.org/jira/browse/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
> >
>
--
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
<https://www.cloudera.com/>
------------------------------
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by Istvan Toth <st...@cloudera.com.INVALID>.
The technical details:
The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with
all of its own dependencies shaded in)
in the /lib directory, along with the log4j slf4j backend jar.
sqlline.py and friends is to be updated to add those to the classpath.
Richard has this already up in https://github.com/apache/phoenix/pull/1239
On Wed, May 26, 2021 at 9:43 PM Josh Elser <el...@apache.org> wrote:
> I think the idea is that we would include a sqlline jar with the Phoenix
> distribution. Context: we had some grief where a sqlline upgrade caused
> user pain because they were relying on specific output from sqlline.
>
> If we have the sqlline jar _not_ packaged inside phoenix-client, then
> users can easily replace the version of sqlline which makes them happiest.
>
> While I agree with Istvan that #1 is the more "correct" option, I'm
> worried about the impact of folks who rely on the phoenix-client.jar to
> be a "batteries included" fat-jar. Removing sqlline from
> phoenix-client-embedded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, larsh@apache.org wrote:
> > 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 <
> stoty@apache.org> 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 <https://issues.apache.org/jira/browse/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
> >
>
--
*István Tóth* | Staff Software Engineer
stoty@cloudera.com <https://www.cloudera.com>
[image: Cloudera] <https://www.cloudera.com/>
[image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
on LinkedIn] <https://www.linkedin.com/company/cloudera>
<https://www.cloudera.com/>
------------------------------
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by Josh Elser <el...@apache.org>.
I think the idea is that we would include a sqlline jar with the Phoenix
distribution. Context: we had some grief where a sqlline upgrade caused
user pain because they were relying on specific output from sqlline.
If we have the sqlline jar _not_ packaged inside phoenix-client, then
users can easily replace the version of sqlline which makes them happiest.
While I agree with Istvan that #1 is the more "correct" option, I'm
worried about the impact of folks who rely on the phoenix-client.jar to
be a "batteries included" fat-jar. Removing sqlline from
phoenix-client-embedded is great, so I'd lean towards #2.
We can see what adoption of phoenix-client-embedded looks like now that
we have it in releases. I imagine most folks haven't yet realized that
it's even an option that's available.
On 5/26/21 1:16 PM, larsh@apache.org wrote:
> 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 <st...@apache.org> 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 <https://issues.apache.org/jira/browse/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
>
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by Josh Elser <el...@apache.org>.
I think the idea is that we would include a sqlline jar with the Phoenix
distribution. Context: we had some grief where a sqlline upgrade caused
user pain because they were relying on specific output from sqlline.
If we have the sqlline jar _not_ packaged inside phoenix-client, then
users can easily replace the version of sqlline which makes them happiest.
While I agree with Istvan that #1 is the more "correct" option, I'm
worried about the impact of folks who rely on the phoenix-client.jar to
be a "batteries included" fat-jar. Removing sqlline from
phoenix-client-embedded is great, so I'd lean towards #2.
We can see what adoption of phoenix-client-embedded looks like now that
we have it in releases. I imagine most folks haven't yet realized that
it's even an option that's available.
On 5/26/21 1:16 PM, larsh@apache.org wrote:
> 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 <st...@apache.org> 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 <https://issues.apache.org/jira/browse/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
>
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by "larsh@apache.org" <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 <st...@apache.org> 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 <https://issues.apache.org/jira/browse/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
Re: [DISCUSS] Unbundling Sqlline and slf4j backend from
phoenix-client and phoenix-client embedded
Posted by "larsh@apache.org" <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 <st...@apache.org> 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 <https://issues.apache.org/jira/browse/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