Mailing-List: contact dev-help@asterixdb.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.incubator.apache.org
Message-ID: <558CF059.9010509@gmail.com>
Date: Thu, 25 Jun 2015 23:25:29 -0700
From: Mike Carey <dtabass@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: dev@asterixdb.incubator.apache.org
Subject: Re: Metadata names generation
References: <308FDBD8-616C-4649-8824-C150B794D5F6@cs.ucr.edu>
	<56C5E538-F605-4AC3-B3AB-C05686B8DF44@cs.ucr.edu>
	<EFAB954A-E9B4-4861-971E-3D191C5428C8@cs.ucr.edu>
	<CAEEsEsRM_kYvD_gb6H1Kej6cbrVh5-Jx+XYfHNFNU_yBPejj=A@mail.gmail.com>
	<CAF+3TUoYJgZ7a8PM-DacWnVtZyoTYzjicCEjiRWeeDkmwwTTOg@mail.gmail.com>
	<CAE1xAnsc3KjUyXQU28g_DNObHmty0ye6B4CMD2Y344Duudjg3w@mail.gmail.com>
	<CANQf6Dor4rSXL8+2p6F5XHSLY+jPa2iuBRHF0BFYEQ=CpnGCgQ@mail.gmail.com>
 <CAE1xAnvqM5BJA3yWU1v+YK3keyxp6--xdEeNwpUyvJDWbQPTtQ@mail.gmail.com>
In-Reply-To: 
 <CAE1xAnvqM5BJA3yWU1v+YK3keyxp6--xdEeNwpUyvJDWbQPTtQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------050803080605050806030302"

--------------050803080605050806030302
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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
>>>>>>
>>>>>>


--------------050803080605050806030302--