Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improving data sources #693

Closed
ikedas opened this issue Jul 17, 2019 · 6 comments
Closed

Improving data sources #693

ikedas opened this issue Jul 17, 2019 · 6 comments
Assignees
Labels
bug design enhancement ready A PR is waiting to be merged. Close to be solved
Milestone

Comments

@ikedas
Copy link
Member

ikedas commented Jul 17, 2019

(Part of) Expected changes

  • Data sources won't overwrite display name (gecos) of existing subscriber: It is assigned only when a new user is added (included) from data source, or if it is added (subscribed) by users.
  • Name of only one data source that was actually included will be shown in subscriber table of web interface.
  • Size of include_sources_subscriber database field will no longer limit the number of datasources.

See details in the PR #516.

Context

These changes will be included in the next beta (6.2.45b.1). For more details about changes see the PR page below.

@ikedas ikedas added bug enhancement design ready A PR is waiting to be merged. Close to be solved labels Jul 17, 2019
@ikedas ikedas added this to the 6.2.46 milestone Jul 17, 2019
@ikedas ikedas self-assigned this Jul 17, 2019
@racke
Copy link
Contributor

racke commented Jul 17, 2019

Why would we limit the size of include_sources_subscriber to varchar(62)? There is no difference in storage for larger field sizes and this field isn't indexed.

@ikedas
Copy link
Member Author

ikedas commented Jul 17, 2019

Why would we limit the size of include_sources_subscriber to varchar(62)? There is no difference in storage for larger field sizes and this field isn't indexed.

You says about issue#692. Currently (until 6.2.44) include_sources_subscriber is defined as varchar(50) by default. Indeed the size itself need not limited, but I considered compatibility.

@racke
Copy link
Contributor

racke commented Jul 17, 2019

Compatibility with what?

@ikedas
Copy link
Member Author

ikedas commented Jul 17, 2019

If the field type was changed to text, sympa.pl --health_check will complain that database structure is broken.

@racke
Copy link
Contributor

racke commented Jul 17, 2019

varchar(255) wouldn't be text and still a lot larger.

@ikedas
Copy link
Member Author

ikedas commented Jul 17, 2019

Anyways it isn't big deal with PR#516.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug design enhancement ready A PR is waiting to be merged. Close to be solved
Projects
None yet
Development

No branches or pull requests

2 participants