[dojo-contributors] dojo.data Schema API

Brian Douglas Skinner skinner at dojotoolkit.org
Wed Aug 29 18:16:26 EDT 2007


Jon Sykes wrote:
> I guess a lot of what would drive the responses to yours 
> and maybe other questions is what is the aim here?
> 
> Is the aim to create some form of client side relational 
> data system?  Or is it to handle data that will be coming  
> back from a source (like an RDBMS)?
> 
> I would assume that the large majority of browser based 
> applications will rely on the server for making the 
> relationships, and serving data in such a way that it is  
> easily manipulated by the client (with the exception of 
> maybe things like offline apps (although from what I  
> understand even the offline apps would have some form of 
> client side data model (gears or such like).
> 
> The destination will probably dictate the direction to 
> take.

Good question.  In my mind, the primary design focus for the dojo.data 
Schema should be the scenario where the datastore is handling data that 
is coming back from a server.  Google Gears and Dojo Offline are 
interesting cases, and it would be cool to get the dojo.data Schema 
stuff to play well with them too, but that seems like a secondary goal.

:o) Brian



> On Aug 27, 2007, at 2:49 AM, Brian Douglas Skinner wrote:
> 
>> Interesting idea.  Allowing for hierarchical schema structures like  
>> that
>> might have the advantage of making the semantics more obvious for
>> somebody who's reading the schema file.  Although, for newcomers
>> approaching this from an RDBMS background, the hierarchical schema
>> structure might make dojo.data seem even more weird and unintuitive.
>>
>> Also, at a practical level, would the hierarchical format create the
>> limitation that the nested definition is "anonymous"?  In the "flat"
>> schema example from the original mail, we had named definitions for  
>> two
>> kinds of items, "Country" and "State".  In this new hierarchical  
>> schema
>> example, it looks as if "State" is just an attribute name, like "ABBR"
>> and "NAME", and there's only a named definition for one kind of item,
>> "Country".  Does that make it impossible for any other kind of item to
>> have an attribute of type State -- for example, impossible to have a
>> definition for "Person", with attributes for "NAME", "AGE", and "HOME
>> STATE"?
>>
>> :o) Brian
>>
>>
>> Jon Sykes wrote:
>>> Not sure if I'm jumping in halfway into this but is there a reason it
>>> isn't something like:
>>>
>>> schema == {
>>>      kinds: {
>>>          Country: {
>>>              attributes: {
>>>                  ABBR: {type: 'String'},
>>>                  NAME: {type: 'String'}
>>>                  State: [
>>>                      attributes: {
>>>                          NAME: {type: 'String'},
>>>                          CODE: {type: 'String'},
>>>                          POPULATION: {type: 'Number'}
>>>                      },
>>>                  ]
>>>              }
>>>          },
>>>      }
>>> }
>>>
>>> Which seems to make more semantic sense in terms of relationships.
>>>
>>>
>>>
>>>
>>> On Aug 21, 2007, at 8:55 PM, Brian Douglas Skinner wrote:
>>>>>>     schema == {
>>>>>>          kinds: {
>>>>>>              Country: {
>>>>>>                  attributes: {
>>>>>>                      ABBR: {type: 'String'},
>>>>>>                      NAME: {type: 'String'}
>>>>>>                  }
>>>>>>              },
>>>>>>              State: {
>>>>>>                  attributes: {
>>>>>>                      NAME: {type: 'String'},
>>>>>>                      CODE: {type: 'String'},
>>>>>>                      COUNTRY: {kind: 'Country'},
>>>>>>                      POPULATION: {type: 'Number'}
>>>>>>                  }
>>>>>>              }
>>>>>>          }
>>>>>>      }
>>>>> What's the COUNTRY field of State?  Is that a reference to a  
>>>>> Country
>>>>> item?   Or the id of a Country item?
>>>>>
>>>>> And if it's the former, how would you query for all states in the
>>>>> USA?
>>>> In the example above, the COUNTRY field was intended to be a  
>>>> reference
>>>> to an item, rather than a foreign key.
>>>>
>>>> To query for all the states in the USA, you could do this:
>>>>
>>>>    store.fetch({query: {COUNTRY: usaItem}});
>>>>
>>>> Or, if the schema were a little different, and if Country also  
>>>> had an
>>>> attribute called STATES, then you could just do:
>>>>
>>>>    store.getValues(usaItem, 'STATES');
>>>>
>>>> Or if you wanted you could have a schema where COUNTRY really was a
>>>> foreign key with {type: 'String'}, rather than an item reference  
>>>> with
>>>> {kind: 'Country'}, and then you could do:
>>>>
>>>>    store.fetch({query: {COUNTRY: 'USA'}});
>>>>
>>>> :o) brian





More information about the dojo-contributors mailing list