Hi Luckydonald, I didn't have time to look at this yet, maybe on Wednesday we will have time to think about it. There are several features that are interrelated and can be used in similar situations: - Abstract entities to define common attributed like modification date, etc. - Relationships which are defined using one side only, so you can link a new entity to previously defined User entity without adding something to it - Extending of previously defined database schema with multiple entities These things are interrelated and probably should be designed together I think we can concentrate on it after the next release, otherwise it will be delayed

if people want duplicates, they can use without_distinct()

Guys, I have a question for all of you. Suppose the following query select((p.id, p.name) for p in Person) returns [(1, 'John'), (2, 'Mike'), (3, 'John'), (4, 'Alex')] What do you expect to be the result of select(p.name for p in Person) ?

In such queries Pony returns unique names, like: ['Alex', 'John', 'Mike'] But some users don't like this behavior, and want ['John', 'Mike', 'John', 'Alex'] instead as a default result. So, I want to think about it a bit more, should we change the current behavior or not. The argument that users says for returning all elements without deduplication is that with current behavior aggregate functions give incorrect result, like, if you do scholarship_values = select(s.scholarship for s in Student) total = sum(scholarship_values) The total result will be incorrect, because of removed duplicates. But in my opinion, aggregates should be calculated inside the query, where they can be calculated efficiently, and not after retrieving potentially big number of elements to Python. I like the current behavior, because if we start returning elements with duplicates, the number of duplicates may be surprisingly big in non-trivial queries. For example, if we execute another query, like select(p.name for p in Person for car in p.cars if car.price > 5000) there will be additional duplicates if a single person owns several cars with a high price. And when query becomes even more complex it becomes very hard to predict how much duplicate values it contains, so it will be dangerous to calculate aggregate functions in Python over the result of a such query anyway. So I tend to keep the current behavior. But maybe I'm miss something, and want to hear valid objections if we should keep all duplicates by default