Re: [Tmapi-discuss] Merging of Constructs

[Benjamin B. <bb-...@bo...>]

Hi Lars and Johannes,

thanks for the clarifications. Now, it's (again) like I always thought it is. :)

I like both ideas (map.commit and the construct.finished thing).

The map.commit does not necessarily take longer than for single
constructs, as single constructs could be marked dirty on write
operations and on commit, only dirty constructs are taken care of. For
bigger chunks, a threshold could be set, e.g. if >30% of the
constructs in the map are dirty, check all. The threshold could
possibly be determined with some simple benchmarks.

The finished-thing would be helpful for APIs sitting on top of TMAPI
and which support some block syntax as outlined in my first example.
Maybe, instead of parent.finished(child) we could define "commit" for
every construct. This could be implemented as
getParent().finish(this). IMHO, this API is slightly cleaner and has
the advantages of both. An open question with this approach is,
whether an engine is allowed to commit earlier (and if yes: when).

Association a1 = tm.createAssoc(type);
Association a2 = tm.createAssoc(types);
a2.createRole...
a2.commit(); // is the engine allowed to also commit a1?

>From the current way of thinking, the answer should be yes, but the
transition to a fully transactional API would be a bit harder then,
wouldn't it?

Best regards,
Benjamin



On Sun, Jul 26, 2009 at 7:27 PM, Johannes Schmidt<top...@fr...> wrote:
> Hi Lars,
>
> Lars Heuer wrote:
>
> [...]
>>>
>>> Construct Parent.finished(Construct child)
>>>
>>
>> Hmm, sorry, but I find that solution a bit ugly. If we want something
>> like that, we should add a "commit" method to the TopicMap interface
>> which can trigger duplicate suppression, writing to the DB etc., but I
>> have to think about the proposal a bit more. This was just my initial
>> reaction. :)
>>
>
> ok. Then I should wait writing down my thoughts. Just to mention one
> point: The idea to bind two constructs (a parent and a child) in
> finished() (or whatever name is chosen) is to limit the dupl. removal
> (to the passed child) in order to make such a process as less
> resource-intensive as possible which is significant in large databases.
>
> Best regards,
> Johannes
>
>> Best regards,
>> Lars
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Tmapi-discuss mailing list
> Tma...@li...
> https://lists.sourceforge.net/lists/listinfo/tmapi-discuss
>