Right, we do... but try reading or writing paragraphs of info in them. The DB fields may support it, but the UI not so much.
__Jason On Tue, Nov 20, 2018 at 9:27 AM Fieck, Brennan <[email protected]> wrote: > We have three such fields for Delivery Services, afaik :P > ________________________________________ > From: Jason Tucker <[email protected]> > Sent: Tuesday, November 20, 2018 7:25 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: Adding a text field in Servers config of TP > > I'm actually a fan of arbitrary text boxes for more than just server > objects. I've been hoping for something like this in delivery service > objects as well, as this sort of field can be used to help document > unusual/custom/snowflake behavior which may not necessarily be obvious to > those who come later with the intention of troubleshooting. Should be used > for communicating with humans, rather than systems. In lieu of versioning > of configs, it could be used to keep a change log for the object as well. > But, again, that's more applicable to DS objects rather than Server > objects, I think. > > __Jason > > On Mon, Nov 19, 2018 at 9:48 PM Gray, Jonathan <[email protected]> > wrote: > > > I'm -1 depending on what the intended use case is. > > > > Generic text fields should only be useful to human operators. In the > case > > where you intend anything to programmatically access that information and > > it's generally useful, you're better off with specific columns per point > of > > data. This is how we ended up with unparsable, yet critical, data in the > > comment fields of physical location table when we should have added real > > columns. The example in the issue is delivery services. The description > > field that I think is being referenced is one of LongDesc, LongDesc_1, or > > LongDesc_2 in the database. Columns should have one purpose and one > > meaning that is clear to a new developer working in the code and > > conceptually plausible to anyone else trying to understand how the system > > works. One compromise, I'm not a huge fan of, would be to allow for > > arbitrary structured data via a column of type jsonb instead of text. > > That's not a great answer from a usability or db theory perspective, but > > it's slightly better than regex parsing. > > > > Jonathan G > > > > > > > > On 11/19/18, 3:09 PM, "Dave Neuman" <[email protected]> wrote: > > > > +1, I am fine with it. That table already has a lot of columns, > > what's one > > more!? > > > > On Mon, Nov 19, 2018 at 2:59 PM Jeremy Mitchell < > [email protected] > > > > > wrote: > > > > > Sounds like server "notes" or a server "description". Seems like a > > fair > > > ask. I don't see the harm in adding an optional column to the > server > > table > > > with type=text for this data. > > > > > > On Mon, Nov 19, 2018 at 2:16 PM Anuj Tyagi <[email protected] > > > > wrote: > > > > > > > Hello Traffic Controllers, > > > > > > > > I discussed this with a couple of ATC users. We have multiple > > > > Description/text fields in Delivery Service configuration of TP. > > > Similarly, > > > > We should also have one text field in servers configuration. My > > use case > > > is > > > > to keep the service/serial id of the servers and any specific > info > > for a > > > > server for which no field is available. > > > > > > > > I have created an issue on GitHub for it earlier: > > > > https://github.com/apache/trafficcontrol/issues/2764 > > > > <https://github.com/apache/trafficcontrol/issues/2764> > > > > > > > > It's not a major change so shouldn't be a problem. If everyone > > agrees, > > > I'd > > > > be interested to add that. > > > > > > > > Thank you > > > > Anuj Tyagi > > > > > > > > > > > > > >
