replies inline
On Thu, Jul 5, 2018 at 9:36 AM Eric Friedrich (efriedri)
wrote:
>
> Would the “permissions” field be better titled as “localizationMethods” or
> “localizationPolicies"? Permissions typically relates to security and access
> control, so it seems a bit out of place here
Yeah, I wa
>Just to be clear, the ordering of "cachegroup permissions" doesn't matter
because it's really a Set not an Array
>we'd have to overhaul TR
Right. I was just pointing out future extensibility, not suggesting we do
that now.
I do think we could debate whether cachegroups or deliveryservices are t
Agreed provided that your join table has no properties (i.e. TableA_id,
TableB_id, order).
On 7/5/18, 9:55 AM, "Volz, Dylan" wrote:
Our APIs will be much easier to use, if we can stop
exposing join tables to the API altogether (e.g.
cachegroup_fallback,
del
replies inline
On Thu, Jul 5, 2018 at 9:24 AM Robert Butts wrote:
>
> +1 on listing them as an array. JSON arrays are defined to be ordered, so
> that lets us use the array order as the lookup order, making it easy to add
> that as a feature in the future.
>
> -1 on array types in the database. It
Our APIs will be much easier to use, if we can stop
exposing join tables to the API altogether (e.g. cachegroup_fallback,
deliveryservice_regex), and only insert them into their proper objects
(cachegroup, deliveryservice), and then manipulate them within the
object
And to be clear, this applies only to cachegroups and not delivery services.
Delivery services have a similar issue with "Deep Caching", "Geolocation
Provider", & "Geo Miss Default Lat/Lon".
- Jonathan
On 7/5/18, 9:36 AM, "Eric Friedrich (efriedri)"
wrote:
Would the “permissions” field
Would the “permissions” field be better titled as “localizationMethods” or
“localizationPolicies"? Permissions typically relates to security and access
control, so it seems a bit out of place here
Also, should we consider adding the fallback list to the allowed localization
methods/policies?
+1 on listing them as an array. JSON arrays are defined to be ordered, so
that lets us use the array order as the lookup order, making it easy to add
that as a feature in the future.
-1 on array types in the database. It's unnecessary denormalization, and
will be harder to deal with in the future.
Inline.
On Thu, Jul 5, 2018 at 9:00 AM, Rawlin Peters
wrote:
> You're not mistaken, Jonathan, that is how the logic basically flows
> today; however, with cachegroup fallback configuration now it can be
> deep[if enabled] -> cz -> geo[if fallback config allows].
>
> Marking a cachegroup as "CZ-o
You're not mistaken, Jonathan, that is how the logic basically flows
today; however, with cachegroup fallback configuration now it can be
deep[if enabled] -> cz -> geo[if fallback config allows].
Marking a cachegroup as "CZ-only" is really about filtering possible
cachegroups in selection *after*
If I'm not mistaken, today the logic is fall through on miss (deep[if enabled]
-> cz -> geo). The suggestion to make a 1:* relationship moves that from being
implicit in the code to explicit choice by the DS owner. Changing the
database/apis is expensive enough that maybe we can't make that ju
Can a cache group have many "routing methods". If not, would one column
(cachegroup.routing_method) suffice where acceptable values are an enum? (
CZ, DEEP, GEO)
On Tue, Jul 3, 2018 at 7:05 PM, Mark Torluemke
wrote:
> Feels like columns in the cachegroup table could go a long way in the short
>
Feels like columns in the cachegroup table could go a long way in the short
term -- routing_cz, routing_geo, routing_deep?
On Tue, Jul 3, 2018 at 1:04 PM, Rawlin Peters
wrote:
> Thanks for the suggestion, Jonathan. I wasn't even thinking about the
> possibility of "deep-only" cachegroups, but I
Thanks for the suggestion, Jonathan. I wasn't even thinking about the
possibility of "deep-only" cachegroups, but I could definitely see
that as a future use case.
Do you envision something like a table of cachegroup permissions
(cachegroup_id, cachegroup_permission enum type), where the enums
wou
Rather than a cz_only flag, it might be more powerful to have a join table
with allowed routing methods. You could cover the same use case, but it would
also allow you to do certain things like deep_only or effectively not-geo.
- Jonathan
On 7/3/18, 12:03 PM, "Rawlin Peters" wrote:
Hey
15 matches
Mail list logo
