Menu
▾
▴
tmapi-discuss
|
From: Hannes N. <h.n...@go...> - 2010-08-30 10:28:57
|
Hi, sometimes it is necessary to clear a topic map without deleting it. With clear I mean the removal of every construct inside the topic map. While memory backends can easily free the memory and recreate a topic map it is more complicated for database backends. One real use case are unit tests. I need to create a topic map, fill it with some constructs and after some asserts want to clear the topic map before filling it again. My proposal is to add a clear method which removes all constructs from the topic map and results in an unreified topic map with its base locator and item identifier. BTW: MaJorToM and Ontopia already have this method. best regards Hannes -- Onotoa - Simply create your Topic Maps schemas. Web: http://onotoa.topicmapslab.de User Group: http://groups.google.com/group/onotoa Code: http://code.google.com/p/onotoa/ http://www.topicmapslab.de/people/Hannes_Niederhausen ====================================== Topic Maps Lab http://www.topicmapslab.de ====================================== ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Lars H. <he...@se...> - 2010-08-30 13:34:46
|
Hi Hannes,
[...]
> One real use case are unit tests. I need to create a topic map, fill
> it with some constructs and after some asserts want to clear the topic
> map before filling it again.
If unit tests are the only use case I'd be against it. You could
create / delete topic maps during setUp() / tearDown() (or use the
JUnit 4.x annotations).
Other opinions?
> My proposal is to add a clear method which removes all constructs from
> the topic map and results in an unreified topic map with its base
> locator and item identifier.
a) Topic maps do not have any base locator, I assume you're referring
to storage address of the topic map (tm.getLocator())
b) I don't see a reason why .clear() should keep the item identifiers
of the topic map. I understood .clear() as short-cut for
final Locator loc = tm.getLocator();
tm.remove();
tm = tmSys.createTopicMap(loc);
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Uta S. <uta...@in...> - 2010-08-30 14:41:54
|
Am 30.08.10 15:35, schrieb Lars Heuer: > b) I don't see a reason why .clear() should keep the item identifiers > of the topic map. I understood .clear() as short-cut for > final Locator loc = tm.getLocator(); > tm.remove(); > tm = tmSys.createTopicMap(loc); I understand .clear() as final Locator loc = tm.getLocator(); // remove reifier, topics, associations ... tm.remove(); tm = tmSys.createTopicMap(loc); Btw: +1 for the clear()-method. Uta |
|
From: Lars H. <he...@se...> - 2010-08-30 14:47:31
|
Hi Uta, [...] > I understand .clear() as > final Locator loc = tm.getLocator(); > // remove reifier, topics, associations ... > tm.remove(); > tm = tmSys.createTopicMap(loc); Yes, but tm.remove() removes also all item identifiers (from the topic map) and "clear()" should behave similarly, do you agree (your single line comment does not mention iids)? > Btw: +1 for the clear()-method. :) May I ask which use cases do you have in mind? Or should it just be a convenience method? Best regards, Lars -- Semagia <http://www.semagia.com> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list <http://tinytim.sourceforge.net/> Open Source Topic Maps engine |
|
From: Uta S. <uta...@in...> - 2010-08-30 15:01:14
|
Hi Lars, > Yes, but tm.remove() removes also all item identifiers (from the topic > map) and "clear()" should behave similarly, do you agree (your single > line comment does not mention iids)? I don't think that the map should have item identifiers after clear() any more, but you may discuss this with Hannes. The map should just be cleared, and unlike remove(), it should still exist. AND clear() should not remove all constructs like remove() does, but -- in case of database backends -- should work on the database directly. > May I ask which use cases do you have in mind? Or should it just be a > convenience method? Database backends like Majortom-DB, see above. Uta |
|
From: Lars H. <he...@se...> - 2010-08-30 15:28:26
|
Hi Uta,
[...]
> cleared, and unlike remove(), it should still exist. AND clear() should
> not remove all constructs like remove()
I *would* remove all constructs but not the org.tmapi.core.TopicMap
object itself. I wonder if the supporters of the proposal assume that
.remove() must be implemented as follows:
public void remove() {
for (Association assoc: this._assocs) {
assoc.remove();
}
for (Topic topic: this._topics) {
topic.remove();
}
}
This is not the case. You can work on your database directly.
[...]
> does, but -- in case of database backends -- should work on the
> database directly.
You can work within .remove() on the DB directly as well.
I have to admit that I don't understand what the .clear()-supporters
want to achieve.
Options so far:
a) Delete everything but not the item identifiers of the topic map
b) Delete everything (including item identifiers) but keep
"external" reifiers (whatever that is)
c) Delete everything within the topic map but the topic map stays
(empty) in the TopicMapSystem
I am not against adding "clear()" to TMAPI if there are good reasons
to change the API. But I wonder if "clear" is the right solution for
the problems which were brought up so far.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Lars H. <he...@se...> - 2010-08-30 15:33:11
|
[...] > I *would* remove all constructs but not the org.tmapi.core.TopicMap > object itself. [...] I meant: """ It *would* remove all constructs but not the org.tmapi.core.TopicMap object itself. """ Best regards, Lars -- Semagia <http://www.semagia.com> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list <http://tinytim.sourceforge.net/> Open Source Topic Maps engine |
|
From: Benjamin B. <bb-...@bo...> - 2010-08-30 16:01:07
|
Hi all,
my 2 cents:
On Mon, Aug 30, 2010 at 5:29 PM, Lars Heuer <he...@se...> wrote:
> Hi Uta,
>
> [...]
>> cleared, and unlike remove(), it should still exist. AND clear() should
>> not remove all constructs like remove()
>
> I *would* remove all constructs but not the org.tmapi.core.TopicMap
> object itself. I wonder if the supporters of the proposal assume that
> .remove() must be implemented as follows:
>
> public void remove() {
> for (Association assoc: this._assocs) {
> assoc.remove();
> }
> for (Topic topic: this._topics) {
> topic.remove();
> }
> }
In most cases this won't work because of TopicInUse exceptions.
>
> This is not the case. You can work on your database directly.
The question is: should each single remove translate to a single db
call or should there be one big call?
> [...]
>> does, but -- in case of database backends -- should work on the
>> database directly.
>
> You can work within .remove() on the DB directly as well.
>
> I have to admit that I don't understand what the .clear()-supporters
> want to achieve.
>
> Options so far:
>
> a) Delete everything but not the item identifiers of the topic map
I guess this was just confusion.
> b) Delete everything (including item identifiers) but keep
> "external" reifiers (whatever that is)
Same here.
> c) Delete everything within the topic map but the topic map stays
> (empty) in the TopicMapSystem
+1. This is my understanding of the initial proposal and this is the
way I'd like to see this added to the api
Best regards,
Benjamin
>
> I am not against adding "clear()" to TMAPI if there are good reasons
> to change the API. But I wonder if "clear" is the right solution for
> the problems which were brought up so far.
>
> Best regards,
> Lars
> --
> Semagia
> <http://www.semagia.com>
>
> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
> <http://tinytim.sourceforge.net/> Open Source Topic Maps engine
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Tmapi-discuss mailing list
> Tma...@li...
> https://lists.sourceforge.net/lists/listinfo/tmapi-discuss
>
|
|
From: Lars H. <he...@se...> - 2010-08-30 15:49:24
|
Hi Benjamin,
[...]
>> object itself. I wonder if the supporters of the proposal assume that
>> .remove() must be implemented as follows:
>>
>> public void remove() {
[...]
>> for (Topic topic: this._topics) {
>> topic.remove();
>> }
>> }
> In most cases this won't work because of TopicInUse exceptions.
Yes, of course. It was just a simplified example. What I wanted to
say: You may do something like
conn.execute("DELETE * FROM topics WHERE tm_id = mytmid;");
You don't have to iterate through the topics / assocs via the API.
>> c) Delete everything within the topic map but the topic map stays
>> (empty) in the TopicMapSystem
> +1. This is my understanding of the initial proposal and this is the
> way I'd like to see this added to the api
Yes, this was also my initial understanding of the proposal. The other
options make no sense at all. So, it would be *effective* the same as
final Locator loc = tm.getLocator();
tm.remove();
tm = tmSys.createTopicMap(loc);
If we all could agree on that, we can discuss if we want to change the
API.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Lars H. <he...@se...> - 2010-08-30 16:45:43
|
[...]
>>> public void remove() {
> [...]
>>> for (Topic topic: this._topics) {
>>> topic.remove();
>>> }
>>> }
>> In most cases this won't work because of TopicInUse exceptions.
> Yes, of course. It was just a simplified example.
[...]
> You don't have to iterate through the topics / assocs via the API.
And if you iterate through the topics / assocs in your TopicMap#remove
implementation, you have to ensure that you don't throw any
TopicInUseException.
Implementations *must* remove all topics without throwing any
exception (see also the signature of the org.tmapi.TopicMap#remove
method which mentions *no* exception at all and *not* the
TopicInUseException in particular).
Sidenote: If you take the JavaDocs literally, implementations
of TopicMap#remove() do not have to remove any topic / assoc at all,
they just have to remove the topic map from the TopicMapSystem, but it
would make sense to remove the topics / assocs to save resources.
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Hannes N. <h.n...@go...> - 2010-08-31 09:03:44
|
Well, we had an internal discussion which concluded to the following proposal: topicMap.clear() should remove every every construct including a reifier of the topic map. The item identifier should be remain in the topic map. This make it possible to reuse a topic map for instance in unit tests. Engines with cache like Ontopia won't allow the following: TopicMap tm = tms.createTopicMap(loc); tm.remove(); tm = tms.createTopicMap(loc); I guess because of some caching issues. In Aranuka I store a topicMap in a session class which will be used to persist POJOs into the topic map. If the user decides to clear the topic map right not it is necessary to remove the topic map and recreate it (which will be a problem in Ontopia) but all what is needed is the removal of all topics and their associations. Yes it is a convenient method and could be implemented by removing every construct by hand, but that wouldn't be very efficient. If we have a clear method which is optimized with the backend. And connecting to the persisting and database can't be a solution. I wonder how the ontopia cache would react if the data in the db is suddenly missing. And by the way calling ((TopicMapImpl)topicMap).getWrapped().clear() does the the thing. I hope this summarizes the whole discussion a bit. best regards Hannes -- Onotoa - Simply create your Topic Maps schemas. Web: http://onotoa.topicmapslab.de User Group: http://groups.google.com/group/onotoa Code: http://code.google.com/p/onotoa/ http://www.topicmapslab.de/people/Hannes_Niederhausen ====================================== Topic Maps Lab http://www.topicmapslab.de ====================================== ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Lars H. <he...@se...> - 2010-08-31 09:26:00
|
Hi Hannes, [...] > topicMap.clear() should remove every every construct including a > reifier of the topic map. The item identifier should be remain in the > topic map. This make it possible to reuse a topic map for instance in > unit tests. Sorry, but I won't support that proposal. If you have problems with your unit tests, it's not the task of TMAPI to solve them. I am not eager to change TMAPI, but I would not vote against a clear() method which leaves an empty topic map in the TopicMapSystem. > Engines with cache like Ontopia won't allow the following: > TopicMap tm = tms.createTopicMap(loc); > tm.remove(); > tm = tms.createTopicMap(loc); > I guess because of some caching issues. Maybe you're trying to fix the wrong holes. If this is an Ontopia issue, why don't you fix Ontopia? [...] > construct by hand, but that wouldn't be very efficient. If we have a > clear method which is optimized with the backend. As said, I am not against clear(), but I am against the proposal to keep the iids. Best regards, Lars -- Semagia <http://www.semagia.com> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list <http://tinytim.sourceforge.net/> Open Source Topic Maps engine |
|
From: Hannes N. <h.n...@go...> - 2010-08-31 10:27:26
|
Hi Lars, > > As said, I am not against clear(), but I am against the proposal to > keep the iids. Actually I never thought of the iids. I don't need them it was just a thought what to do with them. If a clear method exists which removes the iids then its fine for me. best regards Hannes -- Onotoa - Simply create your Topic Maps schemas. Web: http://onotoa.topicmapslab.de User Group: http://groups.google.com/group/onotoa Code: http://code.google.com/p/onotoa/ http://www.topicmapslab.de/people/Hannes_Niederhausen ====================================== Topic Maps Lab http://www.topicmapslab.de ====================================== ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Lars H. <he...@se...> - 2010-08-31 10:38:21
|
Hi Hannes,
[...]
>> As said, I am not against clear(), but I am against the proposal to
>> keep the iids.
> Actually I never thought of the iids. I don't need them it was just a
> thought what to do with them. If a clear method exists which removes
> the iids then its fine for me.
:)
Then you may want to start a vote on clear() to gather more opinions?
Premise: Clear does effectively the same as (yes, again the code
snippet):
final Locator loc = tm.getLocator();
tm.remove();
tm = tmSys.createTopicMap(loc);
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Hannes N. <h.n...@go...> - 2010-08-31 10:43:48
|
Ok, I started a Doodle voting. Please vote at: http://doodle.com/q9w3fc3dxzp62mv7 regards Hannes On Tue, Aug 31, 2010 at 12:39 PM, Lars Heuer <he...@se...> wrote: > Hi Hannes, > > [...] >>> As said, I am not against clear(), but I am against the proposal to >>> keep the iids. > >> Actually I never thought of the iids. I don't need them it was just a >> thought what to do with them. If a clear method exists which removes >> the iids then its fine for me. > > :) > > Then you may want to start a vote on clear() to gather more opinions? > > Premise: Clear does effectively the same as (yes, again the code > snippet): > > final Locator loc = tm.getLocator(); > tm.remove(); > tm = tmSys.createTopicMap(loc); > > Best regards, > Lars > -- > Semagia > <http://www.semagia.com> > > <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list > <http://tinytim.sourceforge.net/> Open Source Topic Maps engine > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Tmapi-discuss mailing list > Tma...@li... > https://lists.sourceforge.net/lists/listinfo/tmapi-discuss > -- Onotoa - Simply create your Topic Maps schemas. Web: http://onotoa.topicmapslab.de User Group: http://groups.google.com/group/onotoa Code: http://code.google.com/p/onotoa/ http://www.topicmapslab.de/people/Hannes_Niederhausen ====================================== Topic Maps Lab http://www.topicmapslab.de ====================================== ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Lars H. <he...@se...> - 2010-08-31 10:52:36
|
Hi Hannes, > I started a Doodle voting. Please vote at: I'd prefer a vote via mailing list. Hm.... this is getting more complicated than it should be... How about adding the clear() proposal to the bug tracker and we simply add it in the next TMAPI version. The clear method does no harm but it's not that important to satisfy a new TMAPI release. Best regards, Lars -- Semagia <http://www.semagia.com> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list <http://tinytim.sourceforge.net/> Open Source Topic Maps engine |
|
From: Lars H. <he...@se...> - 2010-08-31 10:55:55
|
[...] > How about adding the clear() proposal to the bug tracker and we simply > add it in the next TMAPI version. Done <https://sourceforge.net/tracker/?group_id=39237&atid=424686> HTH, Lars -- Semagia <http://www.semagia.com> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list <http://tinytim.sourceforge.net/> Open Source Topic Maps engine |
|
From: Hannes N. <h.n...@go...> - 2010-08-31 11:46:16
|
Okay, I try to code a unit test test in the next days and add the patch to the issue. Hannes On Tue, Aug 31, 2010 at 12:57 PM, Lars Heuer <he...@se...> wrote: > [...] >> How about adding the clear() proposal to the bug tracker and we simply >> add it in the next TMAPI version. > > Done > <https://sourceforge.net/tracker/?group_id=39237&atid=424686> > > HTH, > Lars > -- > Semagia > <http://www.semagia.com> > > <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list > <http://tinytim.sourceforge.net/> Open Source Topic Maps engine > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Tmapi-discuss mailing list > Tma...@li... > https://lists.sourceforge.net/lists/listinfo/tmapi-discuss > -- Onotoa - Simply create your Topic Maps schemas. Web: http://onotoa.topicmapslab.de User Group: http://groups.google.com/group/onotoa Code: http://code.google.com/p/onotoa/ http://www.topicmapslab.de/people/Hannes_Niederhausen ====================================== Topic Maps Lab http://www.topicmapslab.de ====================================== ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Uta S. <uta...@in...> - 2010-08-30 15:56:37
|
Hi Lars,
> Yes, of course. It was just a simplified example. What I wanted to
> say: You may do something like
>
> conn.execute("DELETE * FROM topics WHERE tm_id = mytmid;");
>
> You don't have to iterate through the topics / assocs via the API.
My problem with this is: of course, MY engine may do this. But I want to
be sure that every other engine I may use, has implemented it this way
as well ...
Uta
|
|
From: Lars H. <he...@se...> - 2010-08-30 16:04:34
|
Hi Uta,
[...]
>> say: You may do something like
>>
>> conn.execute("DELETE * FROM topics WHERE tm_id = mytmid;");
>>
>> You don't have to iterate through the topics / assocs via the API.
> My problem with this is: of course, MY engine may do this. But I want to
> be sure that every other engine I may use, has implemented it this way
> as well ...
If an engine implementation iterates through the topics / assocs, it
would do nothing wrong. It may be ineffective but the result would be
the same: The topic map is removed from the TopicMapSystem.
The following must hold true for a TMAPI implementation:
final Locator loc = tmSys.createLocator("http://example.org/map");
final TopicMap tm = tmSys.createTopicMap(loc);
assertNotNull(tm);
assertEquals(tm, tmSys.getTopicMap(loc));
tm.remove();
assertNull(tmSys.getTopicMap(loc));
How it's implemented is completely unimportant and outside the scope
of TMAPI.
And I think it should be possible to create a topic map under the same
storage address of the removed topic map (see Sven's objection that
this might not be allowed).
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Lars M. G. <la...@ga...> - 2010-08-31 13:30:41
|
* Uta Schulze > > [efficient clear() implementation over DBs] > > My problem with this is: of course, MY engine may do this. But I want to > be sure that every other engine I may use, has implemented it this way > as well ... This is out of scope for TMAPI, I'm afraid. We can only require implementations to perform a certain operation. To require them to do it efficiently is not the sort of thing an API standard can or should do. Of course, we can add a note to the effect that implementors are encouraged to implement this directly against the backend, but that's just a bunch of words in a comment, it doesn't guarantee anything. Of course, this is the right way to implement it, but implementors are free to do it some wrong way instead. --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ |
|
From: Lars M. G. <la...@ga...> - 2010-08-31 13:55:40
|
* Lars Heuer > > Options so far: > > a) Delete everything but not the item identifiers of the topic map > b) Delete everything (including item identifiers) but keep > "external" reifiers (whatever that is) > c) Delete everything within the topic map but the topic map stays > (empty) in the TopicMapSystem IMHO c) is the only option that makes sense. --Lars M. http://www.garshol.priv.no/tmphoto/ http://www.garshol.priv.no/blog/ |
|
From: Sven K. <kr...@in...> - 2010-08-30 14:50:17
|
Hi, In my opinion it isn't simply a shortcut of remove() and create(). Some Topic Maps Engines does not allow to create a topic map with the same locator after removing it, in this case the topic map system fails, because the topic map was removed some moments before. On the other hand, the deletion of a topic map is more than simple a clear command. In the case of a RDBMS topic map storage, the created topic map is another topic map than the removed one, because of other IDs. This could be a problem, if the topic map was reified by an external topic representing the topic map. If the topic map will be removed, the reifier lost the reification link ( like expected ), but if the content of a topic map will be removed using clear, the reification between the topic map and the topic keep alive. In my opinion the reification may not removed by using the clear method, except the reifier is a topic of the cleared topic map . TopicMap tm, tm2; ... Topic reifier = tm2.createTopic(); tm.setReifier(reifier); tm.remove(); reifier.getReified() == null OR reifier == null ( because the reifier should be destroyed if reified construct removed ) tm.clear(); reifier.getReified() == tm ! This is not the same and a real use case using reification. Best regards, Sven. Am 30.08.2010 15:35, schrieb Lars Heuer: > Hi Hannes, > > [...] >> One real use case are unit tests. I need to create a topic map, fill >> it with some constructs and after some asserts want to clear the topic >> map before filling it again. > If unit tests are the only use case I'd be against it. You could > create / delete topic maps during setUp() / tearDown() (or use the > JUnit 4.x annotations). > > Other opinions? > >> My proposal is to add a clear method which removes all constructs from >> the topic map and results in an unreified topic map with its base >> locator and item identifier. > a) Topic maps do not have any base locator, I assume you're referring > to storage address of the topic map (tm.getLocator()) > b) I don't see a reason why .clear() should keep the item identifiers > of the topic map. I understood .clear() as short-cut for > final Locator loc = tm.getLocator(); > tm.remove(); > tm = tmSys.createTopicMap(loc); > > Best regards, > Lars -- Sven Krosse M. Sc. Abteilung Automatische Sprachverarbeitung Institut für Informatik | Universität Leipzig Johannisgasse 26 | 04103 Leipzig mail: kr...@in... http://www.topicmapslab.de/ http://tmql.topicmapslab.de/ ====================================== TMRA - International Conferences on Topic Maps Research and Applications TMRA 2010 "Information wants to be a topic map" 29.Sep - 01.Oct 2010, Leipzig, Germany http://www.tmra.de/2010/ ====================================== |
|
From: Lars H. <he...@se...> - 2010-08-30 15:00:19
|
Hi Sven,
[...]
> In the case of a RDBMS topic map storage, the created topic map is
> another topic map than the removed one, because of other IDs. This could
> be a problem, if the topic map was reified by an external topic
> representing the topic map.
TMDM defines no concept of "external" reifiers. Wouldn't it be better
if the topic uses a subject identifier or subject locator representing
the particular topic map?
= http://storage.address.of.the.topic/map
- "My lovely topic map"
.
> of a topic map will be removed using clear, the reification between the
> topic map and the topic keep alive.
Only if you rely on the (internal) identifiers and you use concepts
outside of TMDM in your application.
> In my opinion the reification may not removed by using the clear
> method, except the reifier is a topic of the cleared topic map .
Reification would *always* be removed since TMAPI / TMDM do not care
about "external" reifiers.
[...]
> TopicMap tm, tm2;
> Topic reifier = tm2.createTopic();
> tm.setReifier(reifier);
This shouldn't be allowed since "reifier" belongs to "tm2" and not to
"tm".
Best regards,
Lars
--
Semagia
<http://www.semagia.com>
<http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
<http://tinytim.sourceforge.net/> Open Source Topic Maps engine
|
|
From: Benjamin B. <bb-...@bo...> - 2010-08-30 16:04:44
|
On Mon, Aug 30, 2010 at 5:50 PM, Lars Heuer <he...@se...> wrote:
> Hi Benjamin,
>
> [...]
>>> object itself. I wonder if the supporters of the proposal assume that
>>> .remove() must be implemented as follows:
>>>
>>> public void remove() {
> [...]
>>> for (Topic topic: this._topics) {
>>> topic.remove();
>>> }
>>> }
>
>> In most cases this won't work because of TopicInUse exceptions.
>
> Yes, of course. It was just a simplified example. What I wanted to
> say: You may do something like
>
> conn.execute("DELETE * FROM topics WHERE tm_id = mytmid;");
>
> You don't have to iterate through the topics / assocs via the API.
I agree.
>
>>> c) Delete everything within the topic map but the topic map stays
>>> (empty) in the TopicMapSystem
>
>> +1. This is my understanding of the initial proposal and this is the
>> way I'd like to see this added to the api
>
> Yes, this was also my initial understanding of the proposal. The other
> options make no sense at all. So, it would be *effective* the same as
>
> final Locator loc = tm.getLocator();
> tm.remove();
> tm = tmSys.createTopicMap(loc);
This is mostly* correct for in-Memory engines but this won't work e.g.
with Ontopia RDMBS. See the implementation here:
http://www.google.com/codesearch/p?hl=en#sv9WT6_Yd8A/trunk/ontopia/src/java/net/ontopia/topicmaps/impl/tmapi2/TopicMapImpl.java&q=tmsystem.remove
package:http://ontopia\.googlecode\.com&sa=N&cd=1&ct=rc&l=374
Ontopia RDBMS would need an implementation like the SQL one above (if
it was based directly on an RDBMS...)
* mostly: If an application holds references to the old TM-object
which is cleared (but in the example removed and reinstantiated) the
old object-references would no longer work.
> If we all could agree on that, we can discuss if we want to change the
> API.
If we could all agree on my interpretation of your solution, I'll vote
+1, otherwise I need to be convinced :-P
Best regards,
Benjamin
>
> Best regards,
> Lars
> --
> Semagia
> <http://www.semagia.com>
>
> <http://www.topicmaps.de/mailinglist/> German Topic Maps mailing list
> <http://tinytim.sourceforge.net/> Open Source Topic Maps engine
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Tmapi-discuss mailing list
> Tma...@li...
> https://lists.sourceforge.net/lists/listinfo/tmapi-discuss
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X