Gerardo Ortiz asks:
I was taking a look at the database tables and found that there´s no relational integrity, none of the tables use foreign keys, everything is pk and fields, beeing those fields XML.
Is sakai 2.0 going to be the same way?
Charles Severance responds:
No and Yes. There are three patterns of storage over the history of Sakai:
Sakai 1.0 Alpha - Pretty much stored everything in a flat XML, no foreign key relationship, kind of store. This was back in February 2004. Ick.
Sakai 1.0 Release - Has normalized many of these XML blobs into tables, but not all. Still using soft foreign keys.
Sakai 1.5 is a blend of technologies, some new elements (Help/Syllabus) are stored in Hibernate with real foreign keys and others have been cleaned up so that the relationships were real, but there is still a lot of non-foreign key relationship data structure as you see.
Sakai 2.0 will see a significant move toward Hiberate in the more core areas (like Users, etc). There will still be some old-style tables that we will not have time to convert to Hibernate.
The pattern is to move to completely clean relationships and foreign keys everywhere. But it will take time to make the transition. One of the goals is to make smooth transitions and provide conversions of data over time so as to allow people with production systems to follow right along and upgrade to new releases without the loss of data.
When I delete a user from user tool in admin workspace, the user is eliminated from SAKAI_USER table, but any reference in other tables to that user is still there. Is there any conflict if a delete a username and then create another user with the same exact username?
I believe that is the case. It is one of the reasons that I have always characterized Sakai 1.5 as suitable for medium sized pilots and not large scale production. Remember that the 1.5 release is "half way between 1.0 and 2.0".
One more thing - I forgot to add. In 1.0 we have this "very cool but only slightly useful" ability not to use a database for storage (i.e. Store in flat files) - we needed this because there was no free database that we had access to when that code was written (prior to Sakai project).
Now with HSQL completely free and includable right in the release, as of 1.5, Sakai only stores in a database - even if it is just HSQL in memory.
This is a cool step because now we can introduce the foreign key stuff and have it work both in developer desktops, be continuously QA'd, part of the Quick Start and production systems.
Making this change was not too visible in the 1.5 release but it was a lot of work by the team and is a great foundational step enabling us to get to fixing all the problems you mention.