asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Metadata names generation
Date Fri, 26 Jun 2015 06:25:29 GMT
Do folks not worry at all that . could be confusing in a name due to 
path expressions....?

On 6/24/15 11:17 AM, Steven Jacobs wrote:
> Fieldnames do allow these characters (both of them).
> Steven
>
> On Wed, Jun 24, 2015 at 11:15 AM, Chen Li <chenli@gmail.com> wrote:
>
>> I also prefer "." than "_".  Also want to confirm that field names don't
>> allow these two characters.
>>
>> Chen
>>
>> On Wed, Jun 24, 2015 at 10:52 AM, Steven Jacobs <sjaco002@ucr.edu> wrote:
>>
>>> I second Young-Seek (especially since this is the syntax that users will
>>> use themselves for nested information in queries).
>>>
>>> Steven
>>>
>>> On Wed, Jun 24, 2015 at 10:40 AM, Young-Seok Kim <kisskys@gmail.com>
>>> wrote:
>>>
>>>> It seems better to use "." instead of "_" since "." is more intuitive
>> (at
>>>> least to me) than "_".
>>>> For example, the FacebookUserType_address will be
>>> FacebookUserType.address.
>>>> Best,
>>>> Young-Seok
>>>>
>>>> On Wed, Jun 24, 2015 at 6:31 AM, Mike Carey <dtabass@gmail.com> wrote:
>>>>
>>>>> Much cleaner!  Others should weigh in here to help finalize the
>>>>> conventions....  Thoughts?
>>>>> On Jun 23, 2015 5:31 PM, "Ildar Absalyamov" <iabsa001@cs.ucr.edu>
>>> wrote:
>>>>>> So the general solution is that the generated names should become
>>> less
>>>>>> verbose (consider previous examples):
>>>>>> 1) Anonymous fields naming scheme will change to outerTypeName +
>> “_”
>>> +
>>>>>> fieldName, i.e. “Field_address_in_FacebookUserType” is changed
to
>>>>>> “FacebookUserType_address”
>>>>>> 2) Anonymous collection item naming scheme stays the same, i.e.
>>>>>> “Field_employment_in_FacebookUserType_ItemType” is changed to
>>>>>> “FacebookUserType_employment_ItemType” (name is changed because
the
>>>>>> anonymous field employment naming was changed as described earlier)
>>>>>> 3) Union type completely seizes to exist in metadata (it stays in
>> the
>>>>>> object model though), i.e.
>>>>>>
>> “Type_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookUserType_ItemType”
>>>>>> is changed to “FacebookUserType_employment_ItemType_end-date”,
>> where
>>>> the
>>>>>> type metadata will have an additional field “Optional” with value
>>>> “true”.
>>>>>>> On Jun 19, 2015, at 18:11, Ildar Absalyamov <iabsa001@cs.ucr.edu
>>>>> wrote:
>>>>>>> So I have done half of the fix, which is moved name generation
>>> logic
>>>>> out
>>>>>> of the Metadata node to the client.
>>>>>>> Up to that point nothing in Metadata format was changed, which
>>> makes
>>>> me
>>>>>> wonder whether I should proceed with the following changes.
>>>>>>> As it could be seen from the previous email getting rid of
>>>>>> union-inferred name generation would make auto generated type names
>>>> less
>>>>>> scary, but not entirely.
>>>>>>> Having in mind what Mike mentioned earlier today, should we do
>>>>> something
>>>>>> about other auto generated type name cases?
>>>>>>>> On Jun 19, 2015, at 13:01, Ildar Absalyamov <
>> iabsa001@cs.ucr.edu
>>>>>> <mailto:iabsa001@cs.ucr.edu>> wrote:
>>>>>>>> Currently we are generating the names for inner\anonymous
types
>> in
>>>> the
>>>>>> following cases:
>>>>>>>> 1) Anonymous field in the record.
>>>>>>>> AQL Example:
>>>>>>>> create type FacebookUserType as closed {
>>>>>>>>          id: int32,
>>>>>>>>          name: string,
>>>>>>>>          address: {
>>>>>>>>               address_line: string,
>>>>>>>>               city: string
>>>>>>>>               state: string
>>>>>>>>       }
>>>>>>>>      }
>>>>>>>> The pattern for generating an anonymous field name is "Field_"
+
>>>>>> fieldName + "_in_" + outerTypeName, which translates to
>>>>>> "Field_address_in_FacebookUserType" in the given example
>>>>>>>> 2) Anonymous collection (ordered\unordered list) item
>>>>>>>> create type FacebookUserType as closed {
>>>>>>>>          id: int32,
>>>>>>>>          name: string,
>>>>>>>>          employment: [{
>>>>>>>>               organization-name: string,
>>>>>>>>               start-date: date
>>>>>>>>               end-date: date?
>>>>>>>>       }]
>>>>>>>>      }
>>>>>>>> The pattern for generating an anonymous collection item name
is
>>>>>> collectionFieldName+_ItemType", which translates to
>>>>>> "Field_employment_in_FacebookUserType_ItemType" in the given
>> example
>>>>>>>> 3) Nullable fields
>>>>>>>> Same example as above could be used (end-date field): the
>> pattern
>>>> for
>>>>>> generating a nullable field name is "Type_#" +
>>> fieldsNumberInUnoinList
>>>> +
>>>>>> "_UnionType_" + outerTypeName, which translates to
>>>>>>
>> “Type_#1_UnionType_Field_end-date_in_Field_employment_in_FacebookUserType_ItemType"
>>>>>> in the given example.
>>>>>>>> So you can see these auto generated names could stack up
pretty
>>> fast
>>>>>> and be completely incomprehensible. Just to give you a small flavor
>>> of
>>>>>> that, here is one of the metadata datasets type definitions:
>>>>>>>> open {
>>>>>>>>    DataverseName: STRING,
>>>>>>>>    DatatypeName: STRING,
>>>>>>>>    Derived: UNION(NULL, open {
>>>>>>>>        Tag: STRING,
>>>>>>>>        IsAnonymous: BOOLEAN,
>>>>>>>>        EnumValues: UNION(NULL, [ STRING ]),
>>>>>>>>        Record: UNION(NULL, open {
>>>>>>>>            IsOpen: BOOLEAN,
>>>>>>>>            Fields: [ open {
>>>>>>>>                FieldName: STRING,
>>>>>>>>                FieldType: STRING
>>>>>>>>              }
>>>>>>>>            ]
>>>>>>>>          }
>>>>>>>>        ),
>>>>>>>>        Union: UNION(NULL, [ STRING ]),
>>>>>>>>        UnorderedList: UNION(NULL, STRING),
>>>>>>>>        OrderedList: UNION(NULL, STRING)
>>>>>>>>      }
>>>>>>>>    ),
>>>>>>>>    Timestamp: STRING
>>>>>>>> }
>>>>>>>>
>>>>>>>> And here are couple of fields names, generated for it :)
>>>>>>>>
>> Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType
>> Field_UnorderedList_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType
>> Field_Fields_in_Type_#1_UnionType_Field_Record_in_Type_#1_UnionType_Field_Derived_in_DatatypeRecordType_ItemType
>>>>>>>> Best regards,
>>>>>>>> Ildar
>>>>>>>>
>>>>>>> Best regards,
>>>>>>> Ildar
>>>>>>>
>>>>>> Best regards,
>>>>>> Ildar
>>>>>>
>>>>>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message