This is a post long overdue. I regularly get mail about DataBlock's future so i’m happy to say that (remaining bugs aside) …folks stick a fork in it cause it’s done.  I consider that i have achieved with DataBlock what i set out to do : a small, lean, separation of concerns enforced, easy to deploy, simple API  O/RM. The only thing that is missing now would be LINQ integration (unfortunately that’s a pretty big undertaking and i don’t really have time for this now….at least as a open source. If somebody is interested to sponsor this then contact me).

  So  i guess it’s safe to say that, while bugs will be fixed, no new features will be added.  A related project that i am planning is adding DataBlock business objects like API to Entity Framework. But that’s another story…

I've pushed a small update to DataBlock (1.4.1). If you had problems with version 1.4 please grab the new version.

There are some changes to the BusinessObjects implementation in DataBlock 1.4 .Now there will be 2 types of objects generated for each entity :
- the DataAccessObject : this resembles very much with the old BO objects. It's a typed DAL for a entity. The idea is to use this DAL from a high level "custom" BO.
- the new BusinessObject. This is a clean implementation with supports only the "basic" operation for a entity : Create, Delete, Update and Read. The underline implementation of this is the PersistentObject. This is also used to implement your custom business logic. Write the queries using QueryCriteria and pass them to the persistent object.
So those 2 methods...do we really need them both ? Yeap...choice is the name of the game here. Some people will like to use the built in BOs while others will prefer to use the DAL and build their own BOs.
This way everybody should be happy :)

It was planned for yesterday but i had to push it back due to some bugs. Hopefully not for long.

Small update on DataBlock's next release:
- lots of changes and bug fixes to the Modeler. Finally it will have the option to load the table relations from a existing file.
- paging implementation for sql server. I will implement a paging solution which will work on all SqlServer versions (that means no ROW_NUMBER trick).
- additional library fixes.

See the announcement and details here. Also the forum has been replaced with a discussion list

I had to removed the forum from www.voidsoft.ro/forum due to excessive spamming. So i have created a discussion list at http://groups.google.com/group/datablock-discussions?hl=en .
To post a question about DataBlock you'll just have to mail datablock-discussions@googlegroups.com.

Here's a "from the plane" overview of DataBlock's source code. This might help you to get started if you want to hack it : TableMetadata : this is the "central" type in the DataBlock world. It's the type from which the mapped objects inherit. A instance of this type contains both the data and also members that allow you to manipulate it's metadata. The most useful memebers are :
- TableFields[] : this property returns the array of DatabaseFields[] which map the database table fields. -TableName : the name of the database table - Relations : return the table's relations -Clone : shallow clone. Only the field's values are copied. -GetPrimaryKeyField L returns a reference to the OK field. -GetField(with overloads for field name and index): returns a reference to the specified field. -Attach/RemoveTableMetadata : attach/remove related objects.
PersistentObject : this type contains persistence methods and it's the base type for business objects.
Configuration: contains DataBlock configuration information. This data can be set at runtime and can be read directly from the config file by calling Configuration.ReadconfigData() at startup.
DataBlockException : exeception thrown by the PersistentObject operation which usually wraps database provider exceptions/
ExecutionEngine (resides in the ExecutionEngine) folder : this is the class which connects to the database and runs the queries. Note that the ExecutionEngine "works" in 2 modes : connected (by creating a instance of the type), this means that the database connection is opened for the lifetime of the instance and disconnected (by calling the static methods). In this mode of operation the connection is opended, the query runs and the connection is closed. Also in the same folder are a bunch of helper types like the "ConstaintManager" (creates query executino constraints), FK and PK constraints and the ExecEngine logger).
QueryCriteria : the query criteria is the API that allows you to query the database in a database independent and OOP way. The QueryCriteria type defines the supported operations while the IQueryCriteriaGenerator interface defines the operations that each dataabse provider must implement. The database implementations can be found in the QueryCriteriagenerators folder.
SqlGenerator : the big one. This one generates the SQL (note that this is database independent). The database providers must implement the ISqlGenerator interface which are called by the SqlGenerator for generating the database dependent pieces of the SQL query. another interesting type is the GraphBuilder which generates multiple SQL queries for sequential operations.
DataConvertor : contains conversion methods from and to all the supported types and data strctures.
DataFactory : factory type which initializes the ADO.NET types according to the settings.
Session : contains the DataBlock Session implementation.
This is a small introduction of the DataBlock types and their roles . I hope you'll find it helpfull if you'll try to understand / extend DataBlock. I'll post more detailed information soon.

Note: Parts of this apply to v1.3.4 which will be released new week. DataBlock supports 2 logging methods : - automatic logging of SQL queries (for debugging purposes). This can be enabled/disabled from the config file : <appSettings> <!--log settings--> <add key="LogEnabled" value ="False"/> <add key="LogFilePath" value ="sql.txt"/> </appSettings> or from the Configuration class. Where running from a ASP.NET application make sure the user has rights to write to the specified file. - runtime logging( this will be available in 1.3.4) which allows you to trace sql queries . Here is how to use this Configuration.OnQueryLogging += new QueryLoggingEventHandler(OnLog); protected void OnLog(string data) { //here you can log the query appending the execution context (user name, credentials etc). } Note that the event handler for the QueryLoggingEventHandler is called BEFORE the query will be executed.

Hopefully in the weekend will be online. :)