[Mono-list] Any interest in a new open source project?

Andrew Arnott AndrewArnott@byu.edu
Fri, 30 Jul 2004 10:07:43 -0600
Previous message: [Mono-list] Any interest in a new open source project?
Next message: [Mono-list] ilasm problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This is a multi-part message in MIME format.

------=_NextPart_000_00FB_01C4761D.0D733640
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thanks for all your responses.  I comment on your questions and ideas below.
By the way, I didn't mention that my goal is to make this MS .NET designed
thing work in Mono.  It probably already does, I just haven't tried it.  And
right now the only code I have that is database platform specific is
targeted at SQL Server, and a little code written for OleDb.  I don't know
if MySQL falls under OleDb or not.  

This quickly gets off mono topic.  I should create a mailing list here
shortly.  If you want to join, send me an email and when I make it I'll add
you.

Gert Kello:
> So, could You please share You findings about OPF-s? 
> You might make my life much easier :)

OPFs that I have looked at fall short in what I need to do for two main
reasons:
1) All that I have seen seem to be performance-tuned for small to mid-sized
projects.  I don't know what classifies as a mid-sized project, but I have
potentially millions of rows in tables with several hundred columns.  I
believe that is beyond mid-sized.
2) They all seem to tie a property in a class directly to a column in a
table.  In a few of my classes, I have something akin to a Map (name-value
pairs) that are dynamic at run-time (within certain bounds), so columns in
the persisted tables may be added or removed, and I don't want v1 through
v500 properties to store various variables.  I'd rather have a map for them.


My design is different because it actually brings the business objects
slightly closer to the data-layer, while still keeping them out of the
actual data-access code.  Every business object class derives from a class
in Safari Cell.  The base class does all the grunt work of SQL code.  So,
for example, if your business object has a property to store the FirstName
of a person, the simplified class might look like this:

class Person : Safari.Cell.Row // Row is the class for business objects
{
	private const string FIRSTNAME = "FirstName"; // column in database
	// ...
	public string FirstName
	{
		get
		{
			return (string) base[FIRSTNAME];
		}
		set
		{
			base[FIRSTNAME] = value;
		}
	}
	// ...
}

All the caching, persisting, and some of the validating of the new values
occur in the base class.  I say SOME of the validating because your business
object will usually have some custom validation code that it can put in that
accessor method.  In addition to custom code, the base class does the work
of making sure that a newly assigned string value does not exceed the
defined size in the SQL table.  That way, even though the new value is
cached in a infinite length string in memory, it will be guaranteed to fit
once persisted.

By now you see that there is no external mapping of objects to database
fields.  It is built into your business objects.  This provides the greatest
extensibility, and is part of what helps my design support massive databases
(both in row count and column count).  

Ole Hyldahl Hansen:
> I have put some effort into finding a suitable solution but no 
> acceptable free solutions exists (I could not find any...) 

I am probably going to release Safari Cell under the LGPL license.  X11 is
also rolling around in my mind, but I doubt that will do.  Ideas?
Preferences?  I'm against GPL because I don't consider that free, as
obligations come with it.

Ole, the link you sent is excellent.  I am still perusing it.  My framework
does not match that list very closely.  Some of that is good, I believe, but
much of it is bad, and I would like to develop this project to fit that
criteria more completely.

> the following should hold:
> DataObject o1 = Lookup (<some primary key>); DataObject o2 = Lookup (<same
primary key>); Assert (o1 == o2);

I would more explicitly make your last statement:
Assert ((object)o1 == (object)o2);
Since you can override the operator and make two object references that are
different look the same although they are not.
In answer to that question, yes, I use a hash table to track objects that
are read from the database so that repeated requests are read from the cache
and not recreated.  


Jon Watte:
> If you're running a multi-threaded application, and different threads 
> do work as part of different transactions, then it's pretty clear 
> that changes to o1 should NOT be visible in o2, unless the transaction
> that o1 was viewed as part of commits before you get o2. Transactional 
> semantics require this.

I agree.  That is work yet to be done, but I think it will be fairly easy,
as you say.

------------------

I believe there is enough interest that I feel justified in making this open
source.  My hope is that contributors will make it more cross-platform and
more cross-database, and get some good design ideas from you all.  I have
never hosted my own open source project before.  If you have any
suggestions, please write.

To tie this into Mono, I'd like to move into mono being a primary
development platform, but keep it working on both CLI runtimes.  

------=_NextPart_000_00FB_01C4761D.0D733640
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJkTCCAxkw
ggKCoAMCAQICAwxX1zANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDQwNTE5MTYyMDMwWhcNMDUwNTE5MTYyMDMwWjCBwDEfMB0GA1UE
AxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUQW5kcmV3QXJub3R0QGJ5
dS5lZHUxJDAiBgkqhkiG9w0BCQEWFUFuZHJld19Bcm5vdHRAYnl1LmVkdTEpMCcGCSqGSIb3DQEJ
ARYadGhpc2lzdGhlcGxhY2VAaG90bWFpbC5jb20xJzAlBgkqhkiG9w0BCQEWGHJlbGF0ZV93ZWJt
YXN0ZXJAYnl1LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArlzOF5Csqi69H7O9cETu
bfnVij+sURASLZVKRZHxPZwlaMEuOQeGVkXkWxGjw12LbkbXcR86tfuoAmR0okMtEzl0ygYMHT8o
wqvO2CRqTUMkUdk0ORutlzG1bsNpyWxwxYrpsiOdUuyvF2w8+xJSyTypJKGE3IN5aK9od8un+ucC
AwEAAaN+MHwwbAYDVR0RBGUwY4EUQW5kcmV3QXJub3R0QGJ5dS5lZHWBFUFuZHJld19Bcm5vdHRA
Ynl1LmVkdYEadGhpc2lzdGhlcGxhY2VAaG90bWFpbC5jb22BGHJlbGF0ZV93ZWJtYXN0ZXJAYnl1
LmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAEJwfK49WD9qTJAXXOovageUPPdu
OXDeUAaBUQXNBR0/voePXxDOaiESAnlaEpiGQZgdTio9aEearkADBjMFX37bV9G5oRiBgjAU+rQj
wUweqn+4ZqyJL2xeOQ+eqGMbAg4d/BHYMnbO9FhYxQVVwbJnPeNRHhMpFRIYTDWjgVBTMIIDLTCC
ApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl
cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh
d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x
JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX
1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5E
rHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Ha
o5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH
7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJs
YHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1
iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMR
VGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNp
b24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYc
cGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/
Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAG
AQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJz
b25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMR
UHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX
oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN
3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggLPMIIC
ywIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDFfXMAkG
BSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0
MDczMDE2MDc0MlowIwYJKoZIhvcNAQkEMRYEFDvYr1xvQvA6WQI78R/HDQ31fdc2MGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMV9cwegYLKoZIhvcN
AQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDFfX
MA0GCSqGSIb3DQEBAQUABIGAJhWwp3otVW95Grx3PvVu5+kVueIETj8cFdsmKLTujSOPFMT+8N79
uLm/UnBy83Y81exSazqU+QRKsC7P4q8+fjXuGNtsdmlLqeDBBU8ZRpOeD7AJrVlUccj4/QCzOPo6
duWDoD1+A4NGtqg/J9eGO+ZUCi3cXL3G5zUDJYFbVy0AAAAAAAA=

------=_NextPart_000_00FB_01C4761D.0D733640--
Previous message: [Mono-list] Any interest in a new open source project?
Next message: [Mono-list] ilasm problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]