This project is read-only.

SQL Schema: workspace and collection on entries

Sep 30, 2008 at 10:30 PM
Edited Oct 1, 2008 at 12:01 PM
The entry api to get entries all start with the parameters "string workspaceName, string collectionName". Supporting these is the last large part missing from the SQL entry repository.
These could be extracted from the AtomEntry's Id once it has been constructed, and filtering done then.
Another way too do this would be to save these as separate fields on the entry in the DB so that filtering by workspace and collection can happen on in the SQL query. I think this may be a better option. What do you think?


Oct 1, 2008 at 10:54 PM
Edited Oct 2, 2008 at 9:54 AM
I will probably do it the "separate fields on the entry in the DB" way tomorrow night unless there are any objections.
But using numeric ids on the entry to refer to the workspace and collection tables.
Oct 3, 2008 at 9:11 AM
Edited Oct 3, 2008 at 5:37 PM
Update: the workspace table existed already, the Collection table has become necessary. it's a big one, and I'll be working through the code for it in the days to come.
This has broken some tests, since the Db constraints now require each entry to have a valid collection and workspace, and the code to put entries in these is not present yet.
Oct 4, 2008 at 10:52 AM
I have checked in a file called DomainExtensions.cs in the test project.
It contains extension methods that I am using for finding and filtering.
Obviously this is not a substitute for SQL where clauses, but it's handy.

Would this be appropriate for the Domain namespace? it seems so to me.
Oct 7, 2008 at 10:05 AM
The SQL entry store now correctly deals with Workspace and Collection (assuming that the collection and workspace are found on the database before the entry is created).
I have moved on to testing and implementing other entry retrieval flags - i.e. EditSort
Oct 9, 2008 at 10:08 AM
The various GetEntry methods on the entry repository have parameters that are variations on the same theme. Have you considered using a parameters object to carry all of this data?

http://www.refactoring.com/catalog/introduceParameterObject.html
http://pulihora.blogspot.com/2004/08/methods-with-too-many-parameters.html

I am using such an object internal to the SQL repository, since it makes sense there, since I want to have only one method that has the long select that turns a DB entry into a domain entry. But if used more widely, it could be simpler and more flexible.
Oct 9, 2008 at 3:12 PM
Edited Oct 9, 2008 at 3:12 PM
This sounds like a good idea.  It looks like we should combine all the GetEntries methods and use a Criteria parameter. 
So the following:
IEnumerable<AtomEntry> GetEntriesByDate(string workspaceName, string collectionName,
   DateTime start, DateTime end, bool authorized, int pageIndex, int pageSize, out int totalEntries);

IEnumerable<AtomEntry> GetEntriesByCategory(string workspaceName, string collectionName,
   string term, Uri scheme, bool authorized, int pageIndex, int pageSize, out int totalEntries);

IEnumerable<AtomEntry> GetEntriesByPerson(string workspaceName, string collectionName,
   string name, string type, bool authorized, int pageIndex, int pageSize, out int totalEntries);

IEnumerable<AtomEntry> GetEntries(string workspaceName, string collectionName,
   bool authorized, bool editSort, int pageIndex, int pageSize, out int totalEntries);

IEnumerable<AtomEntry> GetAnnotations(Id id, bool deep,
   bool authorized, int pageIndex, int pageSize, out int totalEntries);

Would become:
IEnumerable<AtomEntry> GetEntries(EntryCriteria criteria);
Oct 9, 2008 at 3:29 PM
Edited Oct 9, 2008 at 4:39 PM
Yes, that's it.
Or to make the crieria object input-only:
 IEnumerable<AtomEntry> GetEntries(EntryCriteria criteria,
out int totalEntries);
Or if you don't view the paging as part of the criteria:
 IEnumerable<AtomEntry> GetEntries(EntryCriteria criteria, int pageIndex, int pageSize, out int totalEntries);

The way the LINQ to SQL repository works, a "criteria" design would also allow other entry filter combinations. e.g. Filter by date and category. The SQL query is only built up from the filters that have been applied when you try to get data out of it.
Would this also work on the File provider?

See the class EntryRepositoryQueryParams for where I'm doing this.
Oct 9, 2008 at 10:31 PM
i added this to the repository project yet I haven't yet deprecated the old methods.
Oct 10, 2008 at 9:48 AM
Ok, that looks good and will allow me to simplify things in the SQL entry repository. Some refactoring of the SQL and mock entry repositories, and the associated test cases will follow.