Max size for custom field string values

What is the maximum size (if any) of a string value for a custom field?

I note that the error codes indicate "description" must be under 255 characters. Do I infer correctly that the size of a string value for a custom field can be unlimited? What is the practical if not the theoretical limit? I ask because if the string value can be "large" then it can contain, for example, an XML or JSON document that fully describes it (according to some user defined schema or parser validation logic) - as opposed to creating multiple fields for logical "features."

I guess the heart of the question is whether a "feature" needs more than one custom field, regardless of its complexity.

The maximum size is around 2GB, but we cut it off long before you get to that point.

You should use custom license fields for control-flow and meta data for and about customers. It shouldn't be used to stuff large amounts of data that is shared between customers.

Also, you should really create separate custom license fields and use the TA_GetFeature("feature_name") API because it's optimized for quick lookup -- O(1) execution time. And you can use the LimeLM web API for quick queiries based on the custom license fields contents.

If you instead stuff a big JSON or XML blob into a single custom license field you lose that quick lookup speed and you lose the ability to efficiently search for custom license fields in LimeLM (interface and web API)

To me, a "feature" can be a complex subsystem that is (or isn't) enabled, or enabled at different levels of functionality, based on customer purchases. Rather than break a logical "feature" into separate KV pairs (that is, into separate LimeLM "features") I thought it would be faster to grab the whole subsystem descriptor once. The subsystem can then process its configuration with just one fast call to TA_GetFeature('<subsystem-key>') and consume whatever it expects to find there, which can be specialized per subsystem.

Anyway there are many ways to skin this cat and I'll take your caution about large strings to heart. I guess I was kind of tempted to look at this open-ended custom fields mechanism like having your own document database (as in a kind of Mongo equivalent to SQLite) and I accept that it wasn't built for that. But I may still experiment with this idea a bit, with the goal to keep string descriptors as small as possible. 🙂

Reply
Discard post