IMPLEMENTATION.txt

Syntax
======

	auto items = dc.select(name, age).from(person).where(qualification == "BA");
	
	OR

	auto items = dc.select(person.name, person.age).from(person).where(person.qualification == "BA");


	OR

	
	auto query = query::select(name, age).from(person).join(book).on(book.author_id == person.person_id).where(qualification == "BA");


	auto items = query.use(db);      //use on db connection

	auto items = query.use(persons,authors); //reuse on local source


Objectives
==========

	- Type-safety.
	- Constraint checks (throughout).
	- Easy programming. Intuitive syntax and semantic.
	- Deferred execution.
	- Different types of data sources: DB collections as well as in-memory collections.
	- Query reuse.

Example Sample Query
====================

select U.business_site_name, U.category_hierarchy_string, C.category_name 
from( (select business_site_name, category_hierarchy_id from business_site as A, category_map as B where A.business_site_id = B.business_site_id) as S 
	   inner join category_hierarchy as T on S.category_hierarchy_id = T.category_hierarchy_id) as U
inner join category as C on C.category_id = U.level1_category_id

TODO LIST
=========

	- clauses (SELECT command)
		- select                                     - DONE
		- from                                       - DONE
		- join {inner, left, right, full, cross}     - DONE 
		- on                                         - DONE
		- where                                      - DONE
		- group by                                   - DONE but without static checks!
		- having                                     - DONE
		- order by { ASC | DESC }                    - DONE but without 'using operator'
		- limit { count | ALL }                      - DONE
		- offset                                     - DONE
		- fetch                                      - DONE

	- clauses (INSERT command)
		- insert into           - DONE

	- clauses (UPDATE command)
		- update                - DONE
		- set                   - DONE
		- where                 - DONE
	
	- sub-query
		- from(sub-query)            - 
	
	- aggregate functions
		- sum                        -
		- avg                        -

	- features
		- implicit truncate conversion of named_tuple when target named_tuple has subset of source tags.   - DONE
		- std::ostream<< for named_tuple, and use default implementation for types which don't support <<. - DONE
		- members of named_tuple should be column<tag>.    - DONE
		- various ways to access value from name_tuple     - DONE
			- member-based : column c = tuple.name;        - DONE
			- tag-base  d  : column c = tuple[name];       - DONE
			- index-tagsed : column c = tuple.at<index>(); - DONE
		- various ways to access value from column    - DONE
			- member-function : T v = column.value(); - DONE
			- function-like   : T v = column();       - DONE
			- implicit conv   : T v = column;         - DONE

	- design and implementations:
		- implement table in terms of named_tuple      - DONE
		- to ease implementation, introduce tag 
		  kinds, pretty much like iterator_category.   
		  e.g  
		  	   using tag_category = column_tag;         
		  	   using tag_category = meta_tag;         
		  	   using tag_category = universal_tag;         

		  Likewise, for tables also.                   - 
		     
	- transaction
		- strategy {(begin, commit) vs (begin, rollback)}   - 
		

CHECK LIST
==========

	- Checks should be done at all stages, for all tags - select, where, and on.

		auto items = dc.select(author.name).from(author).where(person.person_id == 100);
		auto items = dc.select(person.name).from(author).where(author.author_id == 100);
		auto items = dc.select(person.name, author.name).from(author).join(person).on(person.person_id == book.author_id);
		auto items = dc.select(person.name, author.name).from(author).join(person).on(author.author_id == person.person_id);

		All of these MUST FAIL at compile-time:
			- the first will fail, because wrong table is used in where().
			- the second will fail, because wrong table is used in select().
			- the third will fail, because in on() book is not captured, neither in from(), nor in join().
			- the fourth will fail, because person is not used in on().
		
		auto items = dc.select(person.name, person.name).from(person);

		MUST FAIL at compile-time because:
			- duplicate columns appear in the select-clause.

	- The definition of tables must be syntactic sugar, which means they must derive from named_tuple, so that generalized code can be written. 
	  For example, a single implementation of std::ostream<< would work for all tables, as well as for named_tuples!
	  	
	  	struct person : named_tuple<pt::name_t, 
		                            pt::age_t, 
									pt::qualification_t>{};

IMPLEMENTATION REQUIREMENTS and ANALYSIS
========================================

	- Columns
		- there are 3 kinds of tags for columns, viz. 1) normal tags, 2) universal tags, 3) column
			- only column could contain actual value.
			- other tags cannot contain any value.
			- so value of any expression involving column tags depends on the kind of tags.
				- except column, other two tags shouldn't produce any value. 
				- all three tags should be able to produce DB expression in a context which requires it.
		- so define a nested type 'tag_category':
			using tag_category = context_dependent_tag;           //CDT  
			using tag_category = context_independent_tag;         //CIT
			using tag_category = context_independent_value_tag;   //CIVT

		- interface for all tags. note that a tag is also an expression.
			interface   __tagname__ : ___expression__
			{
				using tag_category = implementation-defined; 
				std::string column_name(bool qualify);  //qualify has no effect on generic_tag, as it will return column_name without qualification.
			};
		- interface for all expressions.
			interface  __exression__ 
			{
				template<typename T> T eval() const;
				std::string repr() const;
				template<typename T> operator T() const { return eval<T>(); }
			};

		- expressions : all expressions can produce SQL repr; few can produce values too.
			- simple expressions
				- CDT   op  CDT           -
				- CDT   op  LITERAL       -
				- CIT   op  CIT           -
				- CIT   op  LITERAL       -
				! CIVT  op  CIVT          -
				! CIVT  op  LITERAL       -

				Out of all forms, only the last two (starting with !) can produce VALUE. 

			- mixed expressions
				- CDT   op  CIT           -
				- CDT   op  CIVT          -
				- CIT   op  CDT           -
				- CIT   op  CIVT          -
				- CIVT  op  CDT           -
				- CIVT  op  CIT           -

				None of the mixed expression can produce VALUE!
	- Tables