search

dkubb / axiom

Simplifies querying of structured data using relational algebra
https://github.com/dkubb/axiom
MIT License
459 stars 22 forks source link

Key attributes #13

Closed solnic closed 11 years ago

solnic commented 11 years ago

Still WIP but as always I'm opening early so we can discuss.

dnesteryuk commented 11 years ago

Guys, when do you think you will add support to distinguish simple attributes from attributes which should be treated like id/index? I am trying to use Dm-mapper for working with our internal API and I don't have any option to distinguish when I have to call API for getting a collection of items and when I have to call API to get only one item by its id. By adding some key option to an attribute object or making it to be another object will help me a lot when I turn an relation object into a request for our API. Thanks for your awesome work.

mbj commented 11 years ago

@nest I do not think the "key or not key" information will be added to virtus. The domain layer of an application should not be interested in db-side keys. Most likely you'll specify the "keyness" of an attribute while mapping your domain object to the database.

dkubb commented 11 years ago

@mbj check the project name :) I need to get busy with the rename

@nestd key information will be added very soon. I need it for writable relations, which dm-mapper needs too.

mbj commented 11 years ago

@dkubb, Sorry man ;)

dkubb commented 11 years ago

I'm going to close this PR for now since I'm starting work on this and will be taking it in a different direction.

The idea I have is that a Header will have a set of keys, one of which will be primary. The objects that represent each key will contain attributes and will probably be Header or Header-like. In RA there is no distinction between a key (what RDBMS call a unique index) and a primary key. It's an arbitrary distinction.

I don't think an Attribute object will know if it is a key or not. A key may be compound, and it is also related to the structure of the Header itself. In RA, every attribute in the Header actually belongs to an implicit key since you are dealing with sets of data. If attributes are projected away, or two relations are joined there are ways to infer what the new header's key will be and this will need to happen as part of any operation that returns a new Header object. (this is called "key inference")