is there a way to add in memory index in TAureliusDataset? How?
if not available, I believe could be a great idea. Since Aurelius expose properties that are not mapped (That is good) it could be a way to order not only by table fields, but also by any property exposed.
And please consider TAurelisDataset as a MemoryTable either, I could be using only it for all my needs, I am having to use other DataSet adding more size to my already big project!
hmmm... around this topic: TList has .Sort(IComparer) that I can implement to order it, and solve my need for Detail.
1) Can I do the same for the InternalList from TAureliusDataset? If I understand you load the list according it comes from the defined sql command.
But some cases is easier to change in memory.
2) is there a way to add secondary indexes to a table from aurelius? This could be a second way to solve some of this retrieval situations. The fact that GUID is not the sequential one is messing with some tables, there are many tables that the sequence of append is commonly the same sequence of display, but GUID guarantee to make that out of order, unless is the sequential GUID. (I suggest for XData and RemoteDB to generate the GUID for empty FID at server side using the sequential GUID method, that would be perfect)
would be possible in the future to expose the IComparer of the InteralList? it is an interesting approach, and if the component just add to the TList and dont care of the positioning it would be nice to sort it. Sadly the programmer of TAureliusDataset added a strict private to where the InternalList is defined, so I cannot hack it :)
2) I have already added a ticket suggesting the sequential guid. It is important for those that works with GUID and for client side should work just fine. BUT if you have way to make the RemoteDB/XData generate it at the moment of saving a new record you would end in a very organized way to use GUID company wide, remove the index fragmentation, the slowing down created by using GUIDs, and keep all the records in sequence, like using the TIdGenerator.IdentityOrSequence at database level. If that is not possible (the server assigning the GUID) the client assigning it help in many cases, but is not effective as the server doing that. It all depends on how to get the GUID from the server side (either calling a service to retrieve one, or the server setting the GUID when needed on its side)
Maybe the developer wanted to follow OO principles avoiding publishing everything and thus making it easier to evolve the classes and not break backward compatibility? :)
2) I don't see a feature request for it in Aurelius feature request system? Neverthless, we started discussing this I think but we still do not know the best approach. Server-side sequential guids have the disadvantage you need a roundtrip to the server to grab the guid, and also not all servers support it so you end up with an application that might not behave the same in all servers (or in other words, a feature that is not supported by all of them). A client-side generation would be better but we still do not know the best algorithm approach, something like Guid.Comb in NHibernate but we don't have enough data to conclude it's the best option. If you have any additional reference for it you're welcome to share.
I have sent this before to you, and I assure you that I have created a ticket. But not a big deal
I believe there is the information you need on that article. I was not aware of server differences. The round trip is the difficult part, I know. But the fact of some not support it is not a problem. I know many server products that defines minimal requirements for some services to work. If not available it works either but without that specific support. So if that can be optional, it will be pursued by the developer to have the optimal environment to have the server side SeqGUID. However it should fall to client side. The benefits of server side centralized sequential guid is enormous for the database. I believe that commercially is very interesting feature to promote the product.
As I mentioned, using sequential guid is either database-specific, or platform-specific (in the case of UuidCreateSequential function, which is Windows-only).
We might consider allowing database-specific when available, but the first option will probably be something like generating a guid-comb using own algorithm that works on all platforms at client side.