Does GCS provide any guarantees about object versions ordering when listing objects with their archived versions? Can we rely that newer versions come before older ones?
Yes. Archived objects are returned ordered by their generation number.
Related
The NuGet docs state that
A specific version number is in the form Major.Minor.Patch[-Suffix]
and that NuGet supports Semantic Versioning. However, the same article also contains examples with version numbers consisting of four parts and in fact, there are some relatively widely used packages with such version numbers.
So, are there any disadvantages of using a version like 1.0.0.1 for a NuGet package?
My concrete use case is a database driver where I want the driver version to include the version of the database which already consists of three parts. Using a four part version would leave the last part for the driver itself and the first three are simply the database version it is compatible and tested with.
I'm running into issues because OrientDB's EXPORT and IMPORT don't respect the integrity of RIDs (it is baffling to me that something meant to preserve data doesn't retain ids, but that's a topic for another time). How to export/import OrientDB dumps and retain IDs
According to the documentation, there is something called ___exportImportRIDMap that is a mapping from the old RIDs to the new ones. How does one actually use this in practice? Does anyone have any examples?
Is it possible to directly use Multi-Version Concurrency Control as client of PostgreSQL database? I would like manually browse/add/delete/restore old versions.
My use case requires keeping multiple previous versions of the data (I have a lot of data and a lot of versions).
In official documentation MVCC mechanism is described (https://www.postgresql.org/docs/9.5/static/mvcc-intro.html) but without any APIs to use it directly.
Simply put, no. MVCC isn't intended as a "version repository", and only keeps its "versions" of data long enough to satisfy the requirements of active transactions. Once a transaction concludes any data versions created to ensure data consistency for the transaction are discarded. The "multiple versions" of MVCC refer to differing versions or views of data which may be needed between different transactions. Within a single transaction only a single version of the data is ever visible. If you need to maintain "versions" of your data you'll need to make provisions for doing this yourself.
Best of luck.
I am trying to figure out the best practices with using Hashids and if I should be storing my hash ids in a column in my db or should I be using it as demonstrated within the documentation. i.e. Encoding the Id in one area, decoding it in another.
With my current setup, I have been encoding all of my primary key id's and decoding them when the values are publicly accessible, which is the intended purpose of the module, but I'm worried that the hashes that were uniquely generated for my id's will change at some point in the future, which could cause issues like link share-ability for my application.
Based on this scenario, should I really be storing the generated hash into a column in my db and query that?
Regarding whether you should store the Id or not in the database is really up for you to decide. I would say there is no need to do that.
Whether the hashes will change in the future or not really depends on you updating the package or not, from the page;
Since produced ids might differ after updates, be sure to include exact version of Hashids, so you don't unknowingly change your existing ids.
Don't know which version you are using but I'm the author of the .NET version and I've been trying to follow Semantic Versioning meaning with bug fixes I increase patch, added features (non breaking) increases minor. Would there be a change in how the hashes are generated I would increase major.
I am storing files using GridFS and the C# official driver.
I am mimic-ing a folder structure and am storing the full directory path in the metadata (i.e. /folder1/subfolder1 ). I am also storing multiple versions of a file using the built-in versioning feature of MongoDB.
This allows me to query for the files in a specific folder using :
var filesQuery = Query.EQ("metadata.ParentPath", myParentPath);
var filesMongo = MongoDatabase.GridFS.Find(filesQuery);
My problem is that this query returns all the files, including the old ones.
How can I insert the version parameter and return only the last uploaded files (as used in the FindOne method of the C# driver)?
I don't know how to include it in the query ("version" doesn't work as it's handled with the upload date internally as far as I know).
Thanks !
I can't think of any way you could write the query to return the newest version of each file in your ParentPath. If you were just returning a single file you could sort by the uploadDate descending and take just the first one (just like the driver does), but that trick doesn't work when you are returning all the files in the directory.
You could write a map/reduce job to do this, but that's probably overkill.
You could also add another boolean (e.g. metadata.isCurrentVersion) to your metadata to flag the current version of each file. It would be up to you to clear the flag on all older versions each time you upload a newer version, but it would make it trivially easy to query for just the current versions.
As long as you don't have too many versions of each file I think your best solution is to do that part of the filtering client side.
You probably want to make sure you have an index on metadata.ParentPath also if there are going to be many files stored.