This commit is contained in:
@@ -68,10 +68,24 @@ CURRENT TODOs
|
|||||||
|
|
||||||
DBDUMP
|
DBDUMP
|
||||||
|
|
||||||
|
todo: Turn dbdump into exporter direct to api
|
||||||
|
- "V8 Export"
|
||||||
|
- need login page
|
||||||
|
- checks for presence of map, if found prompts to resume or restart
|
||||||
|
- checks for data at destination and if a new export prompts to erase destination
|
||||||
|
- need route that allows erase any db
|
||||||
|
- need to track exported objects in a map in v7 and clear on demand for fresh export
|
||||||
|
- so can resume an export and can have the map for exporting
|
||||||
|
- replicate v7 code so far involved in import
|
||||||
|
https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
NEW PLAN:
|
NEW PLAN:
|
||||||
|
|
||||||
Export directly via api usage? - Before I do anything, take a long think about making the dbdump do the export straight via API to the server
|
Export directly via api usage? - Before I do anything, take a long think about making the dbdump do the export straight via API to the server
|
||||||
PROS
|
PROS
|
||||||
|
People can't use the dbdump to move to other software!
|
||||||
No code at the server needs to handle v7 shit or be aware of it in any way
|
No code at the server needs to handle v7 shit or be aware of it in any way
|
||||||
export can proceed one object at a time and not involve one massive pile of data at once
|
export can proceed one object at a time and not involve one massive pile of data at once
|
||||||
This would make sense, be clean and would make it way easier at the server end
|
This would make sense, be clean and would make it way easier at the server end
|
||||||
@@ -80,7 +94,10 @@ DBDUMP
|
|||||||
lot of coding needed to be done in v7 laptop, kind of uggo
|
lot of coding needed to be done in v7 laptop, kind of uggo
|
||||||
server will need to be in export mode though or ops only in order to avoid issues
|
server will need to be in export mode though or ops only in order to avoid issues
|
||||||
at client end would need to track what was exported with a dictionary to confirm the existance before re-uploading
|
at client end would need to track what was exported with a dictionary to confirm the existance before re-uploading
|
||||||
|
could this be way slower than a local import from export files? (does it matter?)
|
||||||
THINGS
|
THINGS
|
||||||
|
systemwide readonly mode during import (ops) so users can view the progress without making changes to the objects at the RAVEN end?
|
||||||
|
unless it's so fast that it's irrelevant :)
|
||||||
Special route at server for export?
|
Special route at server for export?
|
||||||
Need authorization stuff, who does it? Ops woudn't normally have rights to biz objects so it would need a bizadminfull I guess
|
Need authorization stuff, who does it? Ops woudn't normally have rights to biz objects so it would need a bizadminfull I guess
|
||||||
Kind of fun working with the api from a plugin like that I guess
|
Kind of fun working with the api from a plugin like that I guess
|
||||||
|
|||||||
Reference in New Issue
Block a user