posts - 84,  comments - 880,  trackbacks - 7


1. Utilize stored procedures and functions to implement some functions in OQL.

2. Use global object version to pin a history point, instead of time.

3. Define interface IVersionable to make elements have unified versions.

4. Use serialized XML string to store queries.

5. Use temporary tables to store the query results and then provide functionality of further query on the results.

6. Each time you begin a transaction, all the unsaved data should be saved into database.

7. Use 'rowversion' column to mark the version of table records.


8. Enable the functionality of Schema history.

9. Maybe Swallow could consolidate some process logics into automatically generated code, and then use the compiler to build them into binary instructions.

This will avoid runtime constructions and greatly improve the performance.

10. Object pools can be divided into sub pools. Each sub pools holds the objects from a specific mapping.

11. Defined some special GUIDs for system preserved objects, like schema objects.

12. Introduce the concept of 'Module/Package' to group the persistent types and global variables.

13. Treat Arrays as collections with fixed size. And allow multi-dimensioned arrays.


14. Scopes should essentially be implemented and handled at the mapping layer. And, in the upper object layer, each reference field can be restricted to a

specific scope of a class.

15. Create reference views for those reference fields, and this will make reference checking much more convenient.

16. From the bottom to the top Swallow can be divided into four components. They are Laser.ToolKit, Laser.Swallow.VirtualDatabase,

Laser.Swallow.ObjectSerializer, and Laser.Swallow.ObjectDatabase. Laser.ToolKit is a reusable component which contains several useful classes including

StringOperator, ObjectReflector, Resourcer and Logger.

17. Add a virtual property IsDataRecord to class PObject.


18. SchemaCenter can be used to publish and synchronize schema definitions for all InterDOW/Swallow sites on the Web. The client can choose wether to import

those schema objects defined on the SchemaCenter, but can not modify them. And, once the definitions has been modified on the center, all the counter-parts

on the clients should be updated automatically. However, if you like, you can make some modifications based on a published schema object and save it as

another local one.

19. Make persistent objects independent from objectbases.

20. Define a collection class to hold the query results of a specific XRelation. Actually this class uses the cache mechenism to accelerit the speed.


21. Collection class for XRelation is dedicated for implementing collection property of persistent types. It can avoid requery each time the program access

the property, and provide a method named Refresh to allow requery on demand.

22. Attach a history link table to each entry of the hashed object pool. This data structure can provide convenience for retrieving historical objects.


23. Native Code Generation: Supports generating code directly in multiple kinds of native programming languages. This feature can automatically generate

applications that can run on their respective platform without Swallow.NET and InterDOW. Native code will run faster, but of course loose the functionality

of schema operations and some other functionalities provided by Swallow. However, still an attractive and unimaginable feature!

24. Applies Singleton pattern on each database provider class.

25. Use the base type name prefix to address the overriden members in a persistent type.

26. Introduce type indicators in the SELECT list in OQL to allow explicit type casting.


27. Swallow may support both Concret Tables and Extended Tables to implement type inheritances.

28. InterDOW should be able to separate into several reusable functional blocks. For example, Organization & Rights Management. Document Management, Workflow

Management, and Web Presentation System.

29. Implement a QueryDesigner to visually generate query conditions.


30. 'UniObject' provides the features of GLUES(Global, Localizable, Unique, Encryptable, Serializable). By UniObjects, all the resource data all over the

world can be unified and uniformed for the purpose of data exchange. PObject in Swallow derives from UniObject.

31. Mapping parts consists of two parts, the hierarchy path delimited by backward slash and the structure path delimited by forward slash. In Swallow, there

are three kinds of mappings, root mapping, branch mapping, and leaf mapping. One root mapping can span multiple tables.

32. Mapping information is necessary for many Swallow data sources or data media, it could be used to locate structured properties or distributed objects.


33. Mapping ID can be changed when moving or copying a persistent object from one data source to another, but not the instance ID. And the OID should refers

to the instance/record ID, the mapping/region will be involved when the full ID is required.

34. The data structure of a Swallow persistent object can be describled or rendered using the Cylinder model. The kernel is the current neutral object, the

vertical axis represents the historical time line, and the peripheral surface consists of localized resource objects for multiple cultures.


35. Just as the .NET Framework did, Swallow allows a persistent object to be associated with several attributes. An attribute itself is also a persistent

object. And, furthure more, user can define their own customized attributes, all the attributes must derive from class PAttribute. This feature is very

useful and powerful. For example, you specify another column data type for a primitive type field. There is another utilization of attributes in InterDOW

textual field can be distiguished among plain text, HTML, XML, or other markup texts, with the help of attributes.

36. Swallow allows customized Value Converters when maps properties of .NET types to those of persistent types.


37. Pointers in Swallow are global pointers, that is a pointer may not only point to a native object in the same database, but also a remote one stored in

another database/datasource. Thus, a Swallow pointer is composed of three parts, they are sequentially ObjectID, RegionID, and SourceID. The last one is

SourceID, it has the least significance, and may be omitted. If it is omitted, the pointer will point to the local copy of the remote object in the same

database, which has the same ObjectID. An integrated global pointer also contains the version number and the culture info.

38. Fields of reference types must keep the same and get synchronized for all the cultures.


39. There are three kinds of modes to open a Swallow data source: Readonly, LockSchema, FullFunctioned. And there are three lock modes when connecting to a

Swallow datasource, they are Exclusive, ShareRead, ShareAll.

40. A Swallow datasource can be schema read-only by nature. In this case the schema will be unchangable whatever the connection mode is.


41. Fields of a persistent type can be set to three states to the outside client: Invisible, Readonly, Modifiable. In normal cases, a Field should be

modifiable, but some special cases Swallow want to make the Field invisible or readonly to the outside, and the value of this special field will be mantained

by the Swallow or some system from the inside. Futhure more, Types could also be Invisible, Readonly, Modifiable. The state can be changed when it is not

SystemPreserved. With the feature introduced above, Mapping in Swallow could be treated as a SystemPreserved Invisible Type, its Fields would also be



42. There are two pools/caches in a Swallow datasource, the DataPool and the ObjectPool. The DataPool is somewhat a copy of database tables cached in the

memory. It is composed of a set of 2-dimensional tables and all the primitive data are stored in the cells of those table. However, it is specialized in

providing the convenience to access data cells by InstanceID and MappingID. In order to save the memory, the hierarchied fields collections are prepared on

tables of the DataPool. All PObject instances that are referring to the same record will point to the same hierarchied collection in DataPool, sharing the

same copy of data. The ObjectPool caches ever built-up PObjects or .NET persistable objects.


43. If a table has subtables then all the version numbers in subtables should be counted into the master table. And the reference count on subtables should

also be aggregated to the master table.

44. Recursive composition of ValueTypes(includes Array, which is treated as a ValueType) must prohibited. For example, ValueType A can not contain A as its

Field. And it is also not permitted if A contains B, and then B contains A again. It is in this case A will contain itself indirectly.

45. UniqueID/Object, InstanceID, RecordID, MappingID.


46. Swallow will provide the security funcitonality at the database level, but it is optional considering the on execution performance. Users can decide

wether turn on the security checking when they access Swallow database. By the way, the user will also be recorded into the history table.

47. It is strongly recommended that the outside application reuse the built-in security system as their own security system. So the security system must be

designed to be open and extendable. That is users can extend the system with the customized functionalities. For example, it allows user defined operations

on data, and allows applying rules on filtering users(database accounts) or data(persistent objects).


48. In order to popularize the use of Swallow, develop ASP.NET Web Controls and Windows Controls to conveniently display Swallow objects on the Web pages and

Windows Forms.

49. Swallow should support connecting remote databases across the Internet.

50. Defines access level on each field of a persistent Type. Then security settings could be set on one level instead of each field.


51. Allows caculations on fields/properties of selected objects. Special syntax is introduced for this functionality, that is Object{Field:expression, ...}.

52. DataSlots are utilized by PObjects to store the actual data. Different PObjects can share the same DataSlot so that their data will be synchronized


53. Unique constraints can be checked on the scope of all the concret tables of a class.

54. Not only Types and Fields have access modifiers, but also each object instance can have. This feature can flexiblly divides the access permissions of any

part of data into several kinds of permission levels. e.g. public, internal, private. Outside users can access public data by default.


55. Design a cache/pool sweeping strategy that allows customization on the priorities/precedences of objects being swept.

56. There may be data centers, registration centers, and authentication centers on the Internet, using Swallow databases to provide services of data sharing,

site registration and account authentication or user identification.

57. Persistent Object Locator can be an address pointer, a named variable, or even a function call which returns a temporary object.


58. Virtual database supports both dialect SQL and interpreted portable SQL.

59. Copying a persistent object can be shadow copy or deep copy, and referring a remote object can be direct reference or cached reference.

60. Define a standard, named GOI(Global Object Identifier) for locating an object in the global. It would also be able to locate and leverage the old legacy

data, by implementing some special object locator on specific data source and providing the same interface that conforms to GOI.


61. Persistent Type can have Calculated Fields defined. These are actually query fields as their values are derived by doing some calculations on the other

fields. These fields are not updatable, they are dedicated for convenient queries.

62. Uni-Object/UuObject represents that the object is Uniformed and Unique.


63. A persistent object can be SystemPreserved, ApplicationPreserved, Synchronized or Local.

64. A persistent pointer can be NullPointer, InvalidPointer, and ValidPointer.

65. PVariable is somehow like static PField, except its declaring type is null. So, maybe in Swallow, all static fields are treated as variables. That is

static fields will be represented using PVariable in Swallow.

66. If a reference typed object occurred in the SELECT list, return the address(ObjectID) together with the version number.

67. Swallow may provide the automatic incremental service for user to get a unique integer as an ID.


68. Two manners to synchronize remote objects: real time synchronization, delayed or scheduled synchronization(more exactly, this is an asynchronized mode).

As there must be a local copy of the remote object, we also call the local one 'Shadow Object'.

69. U = Unified / Unique / Uniformed.

70. GLUES = Global + Localizable + Unified + Encryptable + Serializable.

posted on 2005-03-13 21:18 Laser.NET 阅读(...) 评论(...) 编辑 收藏