Hi Parsa, the main reason why TBC scans all files in your workspace in the beginning is to get the base URI of each file, and to get a complete map of owl:imports between the files to help with refactoring.
One solution I could think of to avoid such connections in the first place (whether you are connected or not), would be to put extra metadata into the connection file (e.g. the .oracle files). Then the engine could simply scan these metadata files to collect the list of owl:imports that this database has. The risk of this is that the metadata files might become out of date, but this is manageable if people only use TBC to edit the ontologies. Another solution would be, as you seem to suggest, to simply not collect the imports of those slower data sources anymore. This is a simpler solution, for the price of a small inconsistency. May be ok though. I will see what I can do to improve this. Thanks for your feedback. Holger On Feb 28, 2009, at 3:20 PM, Parsa Mirhaji wrote: > Holger > This may be somehow difficult to reproduce but happens consistently > with all versions of TBC: > My understanding is that TBC tries to cash or somehow validate > all .owl files in the workspace at the start up. In most instances > the process works fine even if it is not connected to the internet > and some files have references to outbound resources. However, 1) If > you have some Database connection files rather than .owl files in > your workspace, and 2) you are connected to the network or internet, > but 3) the database is not available (for example if it is behind > firewall or needs to be accessed using VPN) the TBC will stall. > > This problem occurs only if the computer is connected some network, > including internet but no connection to DB is possible. To address > this problem one needs to stop the network (disconnect the cable or > turn off the wireless connection) first, start TBC (which apparently > knows that it should not try to connect to DB if there is no > internet or network connection) and once the BC starts and settles, > start the internet or network connection. Then TBC works fine > again. This problem happens with all database types (oracle, > allegro and jenadb). > > However you want to address the problem, I hope a timeout -even a > short one- may not be part of the solution, as it would still take a > long time to start TBC if there are several connection files in the > workspace. For example I have more than 20 database connections in > my workspace and if each of them takes 10 seconds before they fail > it will take more than 3 minutes to time them all out). I would be > happily satisfied myself if you give-up doing the database > connections altogether, even if there is a connection, as for > example in the case of Oracle, it takes a long time to start TBC > even if you are not even opening the oracle databases.... Normally > database files are larger models with slower connections and it > makes it really frustrating when using TBC with database > connections... > > Thanks > Parsa > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
