Replies: 4 comments
-
@vic0824 while probably at some points we're going to introduce auto-increment fields, for now, you could use the RID position but create only one bucket per type. In this way, all the records will go in the same bucket, and the new records will have a record position higher than the previous ones. This is guaranteed by the storage that never recycles RIDs after a deletion. The cons of having one bucket instead of 4 or 8 (the default) are that parallel writes over the same type could be slower. WDYT? You can specify the number of buckets per type as global settings for the new created types, or via API and SQL when you create a new type. |
Beta Was this translation helpful? Give feedback.
-
Tough decision.
exploiting the knowledge that each bucket will never contain more than 1M records.
|
Beta Was this translation helpful? Give feedback.
-
Using the bucket in that way is optimal: you can access all the records of a month without using any index. You could use the first part of the RID that already is the rid = resultSet.next().getIdentity().get();
id = String.format("%06d%06d", rid.getBucketId(), rid.getPosition() % 1000000); |
Beta Was this translation helpful? Give feedback.
-
For the moment, I have implemented the autoincrement using a BeforeRecordCreateListener:
|
Beta Was this translation helpful? Give feedback.
-
I'm migrating a project from Hsqldb to ArcadeDB and I need to find an alternative to the following id field:
id INTEGER GENERATED BY DEFAULT AS IDENTITY(START WITH 1) PRIMARY KEY
which is the traditional auto-increment integer column used often in relational databases.
In my data model such an id as a specific semantic, so it's important to preserve the information that a record is "before" or "after" another record, in terms of id.
I'm trying to use the [@]rid as an alternative in ArcadeDB.
The problem I have is that the [@]rid is essentially a String and its sorting order does not represent the order in which the records were inserted, like the traditional autoincrement integer.
The main issue is that the rid is a composite of two different numbers:
Regardless of the bucket selection strategy, in general there is no guarantee that, if I create first record1 and then record2, the rid of record2 will be > the rid of record1.
As a partial workaround, I'm now thinking of using [bucket_name]_[record_position] as a replacement (computed on-the-fly from the rid), as my custom bucket naming convention ensures a well-defined order.
I'd like to get the bucket name from the bucket id, for a given record.
Currently, this is how I do it:
bucketName = database.getSchema().getType("Order").getBucketIdByRecord(record.toElement(), false).getOSFile().getName().substring(0,7);
Does this require a system call to access the filesystem? Is there a more elegant way?
Anyway, I will still have the problem that the record position, interpreted as a string, will not sort like a number, i.e. 202203_19 will appear before 202203_2.
If I reformat the record position with 0-padding, it will sort correctly but will be very long, e.g. 202203_0000000000000000001.
Other alternatives I need to explore are:
1 - I can control the increment from the application that embeds the ArcadeDB server, but I can't control the insertion from the
Console or from Studio
2 - There is no good way to resume the counter after the application is shut-down and re-started. Either I waste a select query to
find out the current max value, or I write the current max to a file in the shutdownhook
Any suggestions are welcome.
Beta Was this translation helpful? Give feedback.
All reactions