I guess the timeline for this is ~3.1M1 (whenever that might be...
still I am eager to try the new DI stuff in my apps, so once the
configuration switch is over I was going to suggest an M1). In any
event this gives us some breezing room.
Good point on the file falling out of sync. I guess the graph load
algorithm will have to handle that - ignoring deleted/renamed
entities, auto-positioning new entities. Not sure if it stores the
connectors positions as well, but if it does, it can apply the same
approach - if both endpoint entities are still there, keep it,
otherwise remove it.
Andrus
On Dec 24, 2009, at 1:18 PM, Andrey Razumovsky wrote:
> Well, this task in not yet finished and unfortunately these days I'm
> very
> short of time. Guess we'll need to reconsider the saving mechanism
> later
> somehow. But note that if graphs aren't synchronized together with
> datamap
> conflicts may occur. Just imagine situation when someone removes an
> entity,
> but it still exists in your graph! It may be not so easy to handle
> all of
> them
>
> 2009/12/24 Ольга Ткачева <tkachovaolg..mail.com>
>
>> excellent work, but I agree with Andrus.
>> for example: yesterday I need only change DbEntity configuration,
>> but I
>> accidentally chose tab "graph". It create new graph.xml file,
>> but I don't need it, it is really distraction and created commit
>> noise.
>> And I think if I will be use graph, my graphs configuration maybe be
>> uncomfortable for other users.
>> for example: I work only with 6 tables in DB and of course I will be
>> placing
>> it apart from all, but after update my tables change its places,
>> it is really no good.
>>
>>
>>
>> 2009/12/3 Andrus Adamchik <andru..bjectstyle.org>
>>
>>>
>>> On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:
>>>
>>> It doesn't make any sense to have a project-specific piece of
>> information
>>>> stored in preferences.
>>>>
>>>
>>> And still we do that a lot already. There's a bunch of per-screen
>>> Modeler
>>> preferences stored per project (and not in user visible XML
>>> files). If
>> you
>>> move to another machine, you lose it.
>>>
>>> I think the difference here is in a mental view of the graph
>>> layout task.
>>> To you and Andrey it is a part of the ORM modeling work. To me it
>>> is not.
>> It
>>> is a *local* user preference. Something a single developer would
>>> tweak to
>>> his or her liking, kind of like arranging icons on a desktop.
>>>
>>> Let me give you a few examples of why sharing a layout might be bad:
>>>
>>> * 2 developers on the project want to have different layouts,
>>> because
>> they
>>> work with different parts of the model. So they group entities
>> differently.
>>>
>>> * A single developer rearranges the layout multiple times during
>>> the day
>> as
>>> he goes from one task to another.
>>>
>>> * 1 developer uses a 13" notebook, another - 31" screen. Developer
>>> 1 has
>> no
>>> choice, but to optimize the layout for his screen.
>>>
>>> Andrus
>>>
>>>
>>
>>
>> --
>> Olga Tkacheva
>>
>
>
>
> --
> Andrey
This archive was generated by hypermail 2.0.0 : Thu Dec 24 2009 - 07:59:00 EST