@migo33 I understand the notion that project VCs could have a separate existence to those in the original file.
But I have yet to work out fully how that could be implemented in the database because currently all VCs (and the [M]aster) are accessed simply via one index and all are entries in the ‘Items’ structure with the same image name. A ‘Project’ simply contains pointers to those entries in the 'Items structure, i.e. there is only one copy of the data but it is being “shared” between two paths (or many paths because the copy could be in many projects at any one time) one via the directory structure and one via the project structure.
That does not lend itself easily to having independent VCs in the project and what if users want to retain the shared existence, i.e. what is available today, and/or mix and match!
Now you have me really confused!!
While you have two paths to the data only the directory “path” is a “destructive” path, at least on DxPL(Win)!!
The original directory:-
The Project after the mass delete, i.e. an empty Project:-
But a full directory is still present:-
@platypus is this different on the Mac and @migo33 is that what you meant by the deletion operation and by your statement, because your statement seems to imply (to me at least) that when you delete from the project the other (in fact the only real) copy will also be deleted!?
You can add VCs to a project in DxPL(Win) but they will also appear in the original directory view and be accessible in both places. This is what the database looks like after I
- saved the database
- loaded a "blank database
- Navigated to the directory with the huge number of VCs
- Created a project
- Deleted all but one of the VCs with the project selected!
The DxPL view:-
The ‘Sources’ structure which holds the [M]aster (original images) details:-
Please note all images are taken from DxPL(Win)db @platypus it would be good to see the structures used for the DxPL(Mac)db!
The ‘Items’ structure, one entry for every copy held in the database:-
The first entry accessed by the index is the [M]aster
The ‘Projects’ structure:-
The ‘ProjectItems’ structure which is “just” references back to ‘Items’:-
@migo33 essentially there is very little in the ‘Project’ structure except one entry containing the name of the project and its ‘Id’ and another which relates that ‘Id’ to a set of 'ItemId’s, i.e. effectively pointing to the entries in the ‘Items’ structure, there is absolutely no data held in the Projects structure.
Any management logic is in the code and on Win 10 deletion of project “entries” (i.e. “pointers”) has no impact on the original data (according to my tests), you just lose some or all of your ‘ProjectItems’ entries, with no “damage” to the original data.
To implement an “independent” existence of customizations within a project then a new entry would have to be made in ‘Sources’ which could/would have new entries in ‘Items’.
Avoiding a major change to the database the change might stand some chance of being implemented e.g. add an ‘As new’ option to the ‘Create project from current selection’ and ‘Add current selection to project’ which would result in a new image or images being created, either in the same directory but given - or in a separate directory - or …
The issue is that currently ‘Projects’ will not survive a database clear-out and a reload could return to a state that ‘ProjectId’ is re-used and the code would need to be able to handle potential duplicate clashes with re-used ‘ProjectId’ values.
This isn’t rocket science but do you really need this capability or are you looking for a solution to the “problem” that deleting from projects appears to delete from the main directory!?