pascal sets in aurelius/xdata


Is there any chance of supporting pascal sets in aurelius / xdata ?

I like to make use of sets in a lot of my classes/records, and it would be useful if these could be mapped to database columns via aurelius.

I think sets could be mapped either to blobs or strings. In the case of strings it could be a simple comma separated list of the elements of the set).


 TAnimals = (cat, dog, horse);
TAnimalSet = set of TAnimals;

 myAnimals : TAnimalSet;

 myAnimals := [cat, horse];

The above could be stored in the database as a string 'cat,dog'

Hopefully I'm not alone in thinking this would be a beneficial enhancement, and that you could consider it for a future release.



should have said "the above could be stored in the database as a string 'cat, horse' !! Not cat. 

wrong again !! (Time for a break I think). Should be 'not dog'.  

I've done this using setters and getters of a property, so your property is a set but it converts it a string or a number to represent your set in the database.

I've done similar myself in the past, but it would be nice if there was built in support for it !  

I think for now mapping a property with getter and setter is a relatively good solution. If you have a global function like SetToString and StringToSet that's pretty straightforward.

The problem with sets is that people might want to save it in many different ways: a comma-separated list of strings, a comma separated list of integers, an integer with each bit representing an item in the set, saving each item in multiple rows of a table, saving each item in a different boolean field in the database.
Too many possibilities to be offered. And even worse, note that all the Aurelius features should be also work out of the box. That means database creation/update (creating the proper fields and/or tables), and also criteria/query: a simple criteria like Where(Linq['Animals'].Contains('horse')) might create complex queries, and also different set operations should be allowed, like intersection, etc.. 
In summary, very complicated so cost/benefit is extremely high compared to simply using properties with getter/setter...
Hi Wagner

Thanks for your comments.

I understand the complexities, and will continue with getter/setter method.