[Bf-taskforce25] unique integer ids for ID types

[Toni Alatalo]

Nathan Letwory kirjoitti:
> when working on dbblender, and that is precisely ensuring that there
> won't be ID block conflicts across files.
>   

what about keeping the part of the current mechanism that the file in 
which the data is is part of the id? so full id would be filename+idnum.

granted, i can imagine it can be somehow tricky with dbblender and 
perhaps other such non-file-oriented storage solutions like networked 
servers ala verse and opensim .. where you may have data coming in from 
multiple files, perhaps from multiple users on multiple compus, to a 
kind of global store.

> /Nathan
>   

~Toni

> 2009/6/11 joe <joeedh at gmail.com>:
>   
>> For ID blocks, we could just have two uids, one for the ID block and
>> one for the source file it came from.
>>
>> Joe
>>
>> On Thu, Jun 11, 2009 at 12:31 PM, Brecht Van Lommel<brecht at blender.org> wrote:
>>     
>>> Hi Joe,
>>>
>>> On Thu, 2009-06-11 at 07:13 -0600, joe wrote:
>>>       
>>>> I had an idea the other day.  What if we store a unique integer id
>>>> (uid) in ID blocks, bones, nodes, etc?  This would solve a number of
>>>> issues, as I see it:
>>>>
>>>> 1. RNA paths would be faster and more reliable to resolve.  If you
>>>> rename an object, or a bone, or a material, the uid stays the same, so
>>>> there's no need to go through and update existing RNA paths.  And
>>>> looking up integer uids would be much faster then looking up names.
>>>> 2. Things without names (e.g. nodes) require something like this,
>>>> since basing the RNA paths off of simple indices would be far too
>>>> unstable.
>>>> 3. This might work for constraint targets, too; e.g. the constraint
>>>> would store a uid, but present the user with the same UI of typing in
>>>> a bone's name, of course.  This idea would probably need more thinking
>>>> through, however.
>>>>         
>>> I think this would indeed simplify RNA path handling, and avoid messy
>>> code to update RNA paths, or constraint updates on bone renames, etc. So
>>> I'm in favor of this. It doesn't solve the problem of keyframes on
>>> removed data staying there, though it's easy to code a function that
>>> removes all invalid RNA paths (not sure when that would run, but at
>>> least it you don't have to care about it while manipulating data).
>>>
>>> If this should be done for ID blocks too, I'm not sure. With library
>>> linking mixing ID blocks from multiple files, it is a bit harder to keep
>>> such uid's unique. However, for animato we may need to solve this
>>> problem?
>>>
>>> If we have the restriction that RNA paths must always start from an ID
>>> block and can not jump to other ID blocks, there is no problem. I would
>>> really like to have this restriction, but from the animation discussion
>>> that was held it seems like people would like to define animation at
>>> scene or group level too, which would include ID blocks in the path
>>> then.
>>>
>>> In that case, I would still prefer it if an ID pointer + RNA path is
>>> used, where the ID pointer is resolved using the standard mechanism for
>>> it. That moves some of the complexity to the animation system though, if
>>> you want to support duplis, but I think an array of ID pointers + RNA
>>> path would be sufficient to represent such things.
>>>
>>> Brecht.
>>>
>>>
>>> _______________________________________________
>>> Bf-taskforce25 mailing list
>>> Bf-taskforce25 at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>>
>>>       
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>>     
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>