forforf / bufs Goto Github PK
View Code? Open in Web Editor NEWBottoms Up File System - A way of organizing files that's hard to explain in a single line
License: Apache License 2.0
Bottoms Up File System - A way of organizing files that's hard to explain in a single line
License: Apache License 2.0
Although working, the file names and class names are mismatched, as well as some hackery in the spec to get it working (Sometimes BufsInfoAttachment class is used, sometimes the dynamic class, this needs reconciling)
Needs Investigation
Need a way to deal with database corruption. The test suites will break, but a deleting the test database fixes everything (the test db is automatically recreated).
It's intermittent, so I'm not able to recreate it, but while troubleshooting and making no changes, it started working. So it maybe a network error. Regardless, need to analyze the main code to figure out the most elegant way of handling this error if it does occur.
Node operations should persist (maybe treat as nodal data as well?) and the persisted operations checked at run time.
Monitor and clean-up to ensure they're not going to clobber the system.
BufsBaseNode is now structured to accept the Glue Env name as a parameter, however, many specs have the older format where the glue env name is part of the environmental parameters. This issue is cosmetic only, but it would clarify the constructor interfaces and roles of the factory vs the base class.
The database record id is based on the database name (originally for ease of troubleshooting). However, I think this has been baked into a full dependency, which makes replicating problematic, as the old records don't work under the new database name (they do work when copied back to the original db name.
Currently the name of the class (which forms the base of the uniq user ids) is also used in the naming in the persistence layers. This makes it very difficult to do any refactoring that changes the base name. One idea would be to store old name(s), and when a record with the old name is encountered (probably in the rescue part of a begin block), upgrade the class name in the persistence layer. Another idea would be too create a manual tool to iterate through the persistence layers to rename them. Another idea would be to build an abstracted relationship between the class name and the persistence layer ids. This would have to be stored in the persistence layer as well. Or, just never change the class names.
There was some cross-user issue when I changed from one user to another and tried to save to Dropbox.
Provide a helper method that provides the Bufs Class when passed the user_id
Right now the file system model protects newer files from being overwritten by older ones. This is probably a good default behavior, but it may be desirable for the business logic to force an overwrite at some point, so the model should be able to honor that request.
Related to saving node element operations, when creating a new node from a different node, any node element operations should transfer as well.
Currently customized node operations are imported as a Module, however there should be a mechanism to update them during run time
Does the file container get deleted when all files are gone? Or is kept around empty?
Right now, there is different behavior between Node.file_subtract(all_files) and Node.file_subtract(:all). The first would leave the container, the latter would delete the container.
Specifically mysql and s3_sdb
The attachment class naming should be "under the hood" from a user perspective.
If so, then there is no need for the "create node from another node" method, and the standard constructor can be used.
This may be contributing to the unexpected ResourceNotFound errors.
Currently with filesystem, the user primary key (model key) data is used for naming the file directory. Better long term approach is to use a persistence layer key that takes the model key data and creates a filesystem safe name that is mappable back to the original.
So lets say I have a node with a key value of "my::strange::node", that would be saved in the file called "my__strange__node" with "my__strange__node" being the persistence layer primary key. Need to come up with a way to differentiate "my::strange::node" and "my//strange//node" with different persistent layer keys (maybe an iterator at the end for duplicates? "my__strange__node" and "my__strange__node1"?).
Regardless, I'm willing to sacrifice some corner cases of strange character usage to keep things simple and readable.
I think there should be an explicit setter equating node_key and model_key to make clear that linkage. Need to confirm that linkage first though.
There may be overlap between these three variables. Any overlap needs to be eliminated and clearer roles established
Currently attached files are tracked at the node level. However, it would make more sense for FileMgr's to track the list of attached files and update the node when changes occur.
So rather than the Node adding to the list when file attachments are added, the FileMgr would add the file, and update the Node with the current list of files (similar for delete)
Model data should be in a model directory (with a dot name such as .model/ ), so that the user home directory can be used for viewing the data and its structure.
Should it be empty or nil?
Both behaviors currently exist in different glue envs
Combine couchrest host and uri to one field.
Replace ":path" with ":location"
Eliminate ":host" (if used should be part of location)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.