User home dir-based or programamble based org.dslforge.workspace.config.configuration

[kgardas]

Hello,
as mentioned in #45 it would be good either to have (a) programming way to specify workspace location or (b) support to use @user.home in specification of workspace location in extension point or (c) support to use workspace/derby purely in RAM of the current Java process.

The motivation behind this is that we would like to use dslforge-based editor in multi-user setup but strict rule needs to apply: NO data sharing between different application users. That means current dslforge does not obey this rule due to usage of shared workspace for Derby DB and we need to fix that in some possible way. Side-note: for different users of the application we are using different JDK processes and different home-dirs/workspaces to isolate users so far...
Thanks!
Karel

[amlajmi]

Hi @kgardas ,
I don't recommend the programmable way to specify the workspace location, because the root path should be available early on startup for the database to start, and that path should not be modified afterwards. Are you considering to have one database/user ?

[amlajmi]

Just to clarify, in (b) do you mean something like %user.home%/www/ in the extension point contribution? or a static method like @jabiercoding suggested in #45.

[kgardas]

Hi @amlajmi ,
in fact I also think that providing programable way would be the worst solution for this issue. Yes, I'd like to have one database per user to avoid any possible data-leaks between different users. And yes, in (b) I mean %user.home% (Windows?) or $HOME (Unix) or just @user.home (Eclipse launch supported way). The string would be substituted by actual user home directory name and what's over it would be added to it. E.g. in my case @user.home/myprojectworkspace/ would be substituted to /home/kgardas/myprojectworkspace -- and there you can append required .metadata (/home/kgardas/myprojectworkspace/.metadata) and then there you can create derby db as you like and this will surely not confuse our users. :-) -- so basically derby db will use the same workspace like our application is using. I hope this is not a showstopper for dslforge. If it is, no problem we can use different workspace but still this will be created in user home directory to prevent data leaks.
Thanks!
Karel

[amlajmi]

Until now, the file system and the database go together, and I don't see any advantage of using the database if it's not for sharing information among users. Wouldn't it be better to disable it completely in your scenario ?

[kgardas]

@amlajmi There is a possibility to completely disable Derby? If so, I'm all for it in our particular case. Could you be so kind and point me to some information describing how to do it? Also if you do not think this issue is relevant after it just close it. Thanks! Karel

[amlajmi]

This is feasible, the clean way to do it would be to add a boolean flag in the extension point definition, something like enableDatabase which is defaulted to true. Then, add a method in IWorkspaceContribution#isDatabaseEnabled(). In WorkspaceActivator#addingService() check the user contribution and based on that create the entity manager factory, see

dslforge/plugins/org.dslforge.workspace/src/org/dslforge/workspace/internal/WorkspaceActivator.java

Line 101 in 2ea33c3

IPath workspaceRootPath = getWorkspace().getRootPath();

Normally, in the workspace manager, every operation on the file system is followed by the pattern:

		IPersistencyService dbservice = DefaultPersistencyService.getInstance();
		if (dbservice.isRunning()) {
			//do stuff on database
		}

So hopefully there is no additional work to do. If you're taking this path, please create a pull request, it would be nice to make this feature available for all of us, thanks.