sisyphuspf-developers Mailing List for Sisyphus Persistence Framework

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Hi all,
 
Just downloaded and started using Sisyphus today and like what I see but
having an issue which will be a make or break for me...
 
I need to use this on a legacy application, with int's for the SQL2000
identity fields, and with any luck, using the next available auto generated
id from the mapped table.
 
I can see I need to create some sort of class inheriting from
SpfIdGenerator, as in the example IntIdGenerator, but I am not too keen on
using a table to store/create a bunch of next the next available id fields
when SQL will handle this for me.
 
Is this possible, has anyone any experiences and/or code to share.
 
Thank you
 
Matthew
Dallas, TX
 
 
 

I realized that the *DataStoreBuilder objects contained a great amount =
of duplicated code.  To eliminate this, I created the abstract class =
SpfAbstractDataStoreBuilder.  This class implements the =
ISpfDataStoreBuilder interface and is expected to be sub classed for =
each different dataStore.

=20

The implementation details are as follows:

=20

1.	The CreateTable  method is implemented as a virtual method with a =
default implementation.  Currently, the MsSql and MySql  implementations =
don=92t need any other implementation.  The Access DataStoreBuilder does =
need to override the implementation because Access cannot Drop and =
Create tables in the same execution.  See the AccessDataStoreBuilder =
implementation for details.

=20

2.	The table name access code has been refactored into the GetTableName =
method.  This allows the table name to be either defined by the name of =
the class, or by a SpfTypeStorageAttribute.

=20

3.	GetTableDdl and GetColumnDdl are abstract and must be implemented =
within the derived DataStoreBuilder.

=20

4.	GetColumnTypeDdl is a refactoring of the GetSqlTypeDdl methods in the =
original builders.  New builders must implement the overload that has =
two parameters.  This method can use the StorageLength to decide on what =
datatype is returned.  (For Example, for a string column, MySql returns =
=91varchar=92 if the length is < 255 otherwise it returns =91text=92.  =
Access returns a varchar for the same lengths otherwise it returns =
=91memo=92 as the datatype.)

=20

5.	GetTableCreateScript is the main motivation for the refactoring.  A =
suggested fix was posted that got me to looking and I realized that this =
method was duplicated in each builder, unchanged, and the fix would have =
to be applied to each one--- Danger: code needs refactoring :)=20

=20

6.	Finally, the method ExecuteDdl was extracted from CreateTable.  This =
allows an overridden CreateTable to do what is necessary without =
worrying about the Execute and try/catch details.  (Also, I added the =
Debug catch as implemented in the original MySql DataStoreBuilder.

=20

I have yet to test these changes, other than compiling them.  I will =
work on that RSN.

=20

Thanks,

=20

Scott Pascoe

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 9/11/2003
=20

I've been watching the forums.  I apologize for not getting answers in.  =
You can send me your fixes.  I will integrate them and put them in CVS.  =
(I'm not currently using SPF for any live projects.  But I'm continuing =
to try to improve its documentation and implementation.

So, we're glad for any and all contributions.

Thanks,
Scott
> -----Original Message-----
> From: Steve Brown [mailto:del...@us...]
> Sent: None
> To: s-p...@us...
> Subject: Sisyphus
>=20
> Cc: <del...@us...>
>=20
> Message-Id: <E19...@sc...>
> Date: Sat, 09 Aug 2003 06:34:37 -0700
> Return-Path: del...@us...
> X-OriginalArrivalTime: 09 Aug 2003 13:34:39.0708 (UTC)
> FILETIME=3D[FB9FC9C0:01C35E7A]
>=20
>=20
> Hi Scott,
>=20
>    I've tried the forums, and Andy... I've got a bunch of fixes
>=20
> to send somewhere for Sisyphus - can you let me know where
>=20
> to send them? I obviously don't have CVS access at the
>=20
> moment, but the fixes would be good to be included... I don't
>=20
> really want to fork the project!
>=20
>=20
>=20
> Look forward to hearing from you
>=20
> Steve
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.507 / Virus Database: 304 - Release Date: 8/4/2003
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.507 / Virus Database: 304 - Release Date: 8/4/2003
=20

Hi!

I made some changes to make SisyphusPF website accessible at 
http://sisyphuspf.sourceforge.net/
Previously it was only available at 
http://sisyphuspf.sourceforge.net/home.htm

I also changed menu on the site a little, just to include link to 
Project Page (http://www.sourceforge.net/projects/sisyphuspf)

The last change is replacement of source code listings with 
syntax-colored pages.

Unfortunatly I did nothing to improve the content, it's all just about 
the presentation.

Regards,
Vlad.

Well, finally=85.

=20

I got the new implementation of the Sisyphus.DataStore committed to CVS =
this evening.  The Access, MsSql and Oracle datastores are now in their =
own namespaces and DLL=92s.

=20

Thanks,

Scott

-----Original Message-----
From: Scott A. Pascoe=20
Sent: Thursday, June 05, 2003 10:32 PM
To: Vlad Romanenko
Cc: sis...@li...
Subject: RE: [Sisyphuspf-developers] RE: Thoughts about the =
Sisyphus.Impl namespace

=20

I was looking at the new OracleDataStore and noticed that there is no =
OracleDataStoreBuilder code.  Hopefully we can build Oracle tables on =
the fly.

=20

On the DataStoreFactory, I=92m not really strong on the factory pattern. =
 Could you give me an example of the implementation of one of your =
create functions?

=20

I=92m planning to add a new project within the Spf Solution, actually, =
it would be four projects as follows:

=20

            DataStore (Sisyphus.DataStore.dll)

                        Containing the DataStoreFactory class =96 =
anything else?

            DataStore/Access (Sisyphus.DataStore.Access.dll)

                        Containing the AccessDataStore* objects

            DataStore/MsSql (Sisyphus.DataStore.MsSql.dll)

                        Containing the SqlDataStore* objects

            DataStore/Oracle (Sisyphus.DataStore.Oracle.dll)

                        Containing the OracleDataStore* objects

=20

Do you think this would be an effective approach?

=20

Thanks,

Scott

-----Original Message-----
From: Vlad Romanenko [mailto:vl...@us...]=20
Sent: Thursday, May 29, 2003 9:18 AM
To: sis...@li...
Subject: RE: [Sisyphuspf-developers] RE: Thoughts about the =
Sisyphus.Impl namespace

=20

Scott, I think that you are absolutely right!

I had similar thoughts also and now I think it's the best time to do =
this, because we are about to add OracleDataStore.

=20

Would you also take care of adding OracleDataStore?

Pascal RECCHIA emailed me two files - OracleDataStore.cs, =
OracleIDGenerator.cs, but I hadn't time yet to look them through and =
commit to CVS.

=20

I also think that we should eliminate references to Util from Core and =
Impl, because they do not really use anything from Util.

If you don't mind, I can do it.

=20

As for runtime DataStore selection, the difference in implementation is =
primarily due to their constructors. We can easily add DataStoreFactory =
class, which will have overloaded methods for each DataStore:

public class DataStoreFactory {
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string =
p_Database)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string =
p_Database, string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string =
p_ConnectionString)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile, =
string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile, =
string p_User, string p_Password, bool p_Create)
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)=20
    public ISpfDataStore CreateSqlDataStore(string p_Datasource)
    public ISpfDataStore CreateSqlDataStore(string p_Datasource, string =
p_User, string p_Password)=20
}

Regards,

Vlad.

=20

-----Original Message-----
From: sis...@li... =
[mailto:sis...@li...] On Behalf Of =
Scott A. Pascoe
Sent: Wednesday, May 28, 2003 5:53 AM
To: sis...@li...
Subject: [Sisyphuspf-developers] RE: Thoughts about the Sisyphus.Impl =
namespace

I=92ve been thinking for quite a while about the Sisyphus.Impl =
namespace.  As we add DataStore implementations, the current =
implementation will force the inclusion of significant baggage.

=20

What do you think about changing the current implementation to something =
like the following:

=20

Sisyphus.DataStore.Access

Sisyphus.DataStore.SqlClient

Sisyphus.DataStore.Oracle

=20

and so on=85.

=20

Each of these implementations could be stored in a separate dll, thereby =
keeping the Oracle stuff from being pulled in when a programmer is only =
interested in the Access.

=20

As an additional idea, I been thinking about the possibility of enabling =
the DataStore to be selected at runtime, instead of compiletime.  One of =
the issues here is the differences in implementations between the =
various DataStores.  I=92m not sure right now, how we would make that =
feature work.  Any ideas welcome=85.

=20

If I get a consensus of go on the change, I can begin working on the =
idea.  Let me know what you guys think about these ideas --- am I full =
of water or is this a good idea?

=20

Thanks,

=20

Scott Pascoe=20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 6/1/2003



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 6/1/2003



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003
=20

I was looking at the new OracleDataStore and noticed that there is no =
OracleDataStoreBuilder code.  Hopefully we can build Oracle tables on =
the fly.

=20

On the DataStoreFactory, I=92m not really strong on the factory pattern. =
 Could you give me an example of the implementation of one of your =
create functions?

=20

I=92m planning to add a new project within the Spf Solution, actually, =
it would be four projects as follows:

=20

            DataStore (Sisyphus.DataStore.dll)

                        Containing the DataStoreFactory class =96 =
anything else?

            DataStore/Access (Sisyphus.DataStore.Access.dll)

                        Containing the AccessDataStore* objects

            DataStore/MsSql (Sisyphus.DataStore.MsSql.dll)

                        Containing the SqlDataStore* objects

            DataStore/Oracle (Sisyphus.DataStore.Oracle.dll)

                        Containing the OracleDataStore* objects

=20

Do you think this would be an effective approach?

=20

Thanks,

Scott

-----Original Message-----
From: Vlad Romanenko [mailto:vl...@us...]=20
Sent: Thursday, May 29, 2003 9:18 AM
To: sis...@li...
Subject: RE: [Sisyphuspf-developers] RE: Thoughts about the =
Sisyphus.Impl namespace

=20

Scott, I think that you are absolutely right!

I had similar thoughts also and now I think it's the best time to do =
this, because we are about to add OracleDataStore.

=20

Would you also take care of adding OracleDataStore?

Pascal RECCHIA emailed me two files - OracleDataStore.cs, =
OracleIDGenerator.cs, but I hadn't time yet to look them through and =
commit to CVS.

=20

I also think that we should eliminate references to Util from Core and =
Impl, because they do not really use anything from Util.

If you don't mind, I can do it.

=20

As for runtime DataStore selection, the difference in implementation is =
primarily due to their constructors. We can easily add DataStoreFactory =
class, which will have overloaded methods for each DataStore:

public class DataStoreFactory {
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string =
p_Database)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string =
p_Database, string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string =
p_ConnectionString)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile, =
string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile, =
string p_User, string p_Password, bool p_Create)
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)=20
    public ISpfDataStore CreateSqlDataStore(string p_Datasource)
    public ISpfDataStore CreateSqlDataStore(string p_Datasource, string =
p_User, string p_Password)=20
}

Regards,

Vlad.

=20

-----Original Message-----
From: sis...@li... =
[mailto:sis...@li...] On Behalf Of =
Scott A. Pascoe
Sent: Wednesday, May 28, 2003 5:53 AM
To: sis...@li...
Subject: [Sisyphuspf-developers] RE: Thoughts about the Sisyphus.Impl =
namespace

I=92ve been thinking for quite a while about the Sisyphus.Impl =
namespace.  As we add DataStore implementations, the current =
implementation will force the inclusion of significant baggage.

=20

What do you think about changing the current implementation to something =
like the following:

=20

Sisyphus.DataStore.Access

Sisyphus.DataStore.SqlClient

Sisyphus.DataStore.Oracle

=20

and so on=85.

=20

Each of these implementations could be stored in a separate dll, thereby =
keeping the Oracle stuff from being pulled in when a programmer is only =
interested in the Access.

=20

As an additional idea, I been thinking about the possibility of enabling =
the DataStore to be selected at runtime, instead of compiletime.  One of =
the issues here is the differences in implementations between the =
various DataStores.  I=92m not sure right now, how we would make that =
feature work.  Any ideas welcome=85.

=20

If I get a consensus of go on the change, I can begin working on the =
idea.  Let me know what you guys think about these ideas --- am I full =
of water or is this a good idea?

=20

Thanks,

=20

Scott Pascoe=20


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.487 / Virus Database: 286 - Release Date: 6/1/2003
=20

It is necessary to modify the method getIsDirty of
SpfEntity Class. 


public bool GetIsDirty() { 

// Look for a changed field 

SpfEntityStorageDefn thisEntityDefn =
SpfEntityDefnCache.Get(this.GetType()); 

foreach (SpfFieldDefn fieldDefn in
thisEntityDefn.FieldDefns) { 

object currentFieldValue =
fieldDefn.Member.GetValue(this); 
object originalFieldValue =
m_OriginalValueTable[fieldDefn.Member.Name]; 

if(currentFieldValue != null) 
{ 
if (!currentFieldValue.Equals(originalFieldValue)) 
{ 
return true; 
} 
} 
else 
{ 
if(originalFieldValue != null) 
{ 
return true; 
} 
} 

} 

I posted the information on Open Discussion Forum, too.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Hi,
About the future of Sisyphus.
We are a team of three developers. We would like to
join your project.

We have three future functionalities in mind :

Meta Data - provides a way to export attributes
SpfAttributes (SpfTypeStorage, ...) in a document XML
to add an abstract level.

Stored procedures

Child collections as you mentionned it above.

Thanks.

 ---
sis...@li... a
écrit : > Send Sisyphuspf-developers mailing list
submissions
> to
> 	sis...@li...
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 
>
https://lists.sourceforge.net/lists/listinfo/sisyphuspf-developers
> or, via email, send a message with subject or body
> 'help' to
> 	sis...@li...
> 
> You can reach the person managing the list at
> 	sis...@li...
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Sisyphuspf-developers
> digest..."
> 
> 
> Today's Topics:
> 
>    1. Future of SisyphusPF (Vlad Romanenko)
>    2. RE: Thoughts about the Sisyphus.Impl namespace
> (Scott A. Pascoe)
>    3. RE: RE: Thoughts about the Sisyphus.Impl
> namespace (Vlad Romanenko)
> 
> --__--__--
> 
> Message: 1
> From: "Vlad Romanenko"
> <vl...@us...>
> To: <sis...@li...>
> Date: Sun, 11 May 2003 17:24:41 +0300
> Subject: [Sisyphuspf-developers] Future of
> SisyphusPF
> 
> Hi all!
> 
> I have some thoughts about the future of the
> project.
> 
> Today there is a demand for object persistence
> frameworks for .Net
> But there exists very few frameworks.
> I personally know about 2 commercial frameworks:
> 
> 1) DeKlarit (http://www.deklarit.com/)
> Its a powerful RAD tool and persistence library with
> tight integration
> with Visual Studio.Net. (It costs $899)
> It's last version 2.0 is very featurefull (according
> to description on
> the website).
> 
> 2) .net Persistence
> (http://www.objectpersistence.com/)
> Its a simple persistence library. It's last version
> 1.1.0 costs $395.
> It's quite similar to Sisyphus 1.2.9. It doesn't
> have advanced features
> such as many-to-many relation etc.
> 
> There is only one open-source persistence framework
> and it's Sisyphus.
> That was the reason why I used it and joined its
> development.
> But as I see, there are few users and developers
> that are using
> Sisyphus.
> And things will not change to the better... Because
> Sisyphus will have
> strong competitor in nearest future.
> 
> There are two primary competitors:
> 1) Microsoft. It's planning to release an object
> persistance framework
> (named ObjectSpaces) together with next major
> version of .Net Framework.
> See more details about it:
>
http://my.execpc.com/~gopalan/dotnet/object_spaces/object_spaces.html
>
http://hosting.msugs.ch/DotNetRox/articles/Art07.html
> 
> 2) Open-source port of some popular Java persistance
> framework.
> Such port for Hibernate has recently started and has
> good progress so
> far.
> http://sourceforge.net/projects/nhibernate/
> 
> Its obvious that Sisyphus will fail to compete with
> both of them.
> So I am asking myself how do I want to be involved
> in Sisyphus and what
> direction should the project follow.
> 
> Sisyphus has some advantages that can make it a good
> choice for some
> projects.
> One of such advantages is its modularity and modest
> size (comparing to
> Hibernate for example).
> This will enable anyone to modify project's sources
> to fit their needs.
> (As I did with many-to-many relations). For the same
> reason (ease of
> modifications) it has advantage over Microsoft
> libraries which will be
> closed.
> 
> So what we need to do?
> We should provide good comparison of Sisyphus and
> other frameworks.
> We should ensure better possible compatibility with
> other persistance
> frameworks. If we were trying to be compatible,
> users will feel
> themselves safer using Sisyphus.
> We should make some promotion of the project...
> 
> Here is my vision for the future of the project.
> I personally would like to work on my contributions
> (many-to-many
> mappings) to make them compatible to other
> frameworks. I'll look at
> abovementioned frameworks and will try to match
> behavior and syntax used
> for many-to-many relations closer to them.
> 
> I'm thinking on changing current syntax to something
> similar to
> ObjectSpaces or Hibernate.
> The following examples aren't very intuitive:
> [SpfChildStorage(ForeignKey = "PersonDetailsID",
> IsReference = false)]
> [SpfChildStorage(ChildType = typeof(Candidate),
> ForeignKey =
> "CandidateID",
>      ParentKey = "VacancyID", AssociateTable =
> "CandidateListMap")]
> 
> I think the core architecture is great and I just
> want to make my
> contributions better, learning from other
> framework's.
> 
> Vlad.
> 
> 
> 
> --__--__--
> 
> Message: 2
> Date: Tue, 27 May 2003 21:53:16 -0500
> From: "Scott A. Pascoe"
> <ma...@pl...>
> To: <sis...@li...>
> Subject: [Sisyphuspf-developers] RE: Thoughts about
> the Sisyphus.Impl namespace
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C324C4.49C9F357
> Content-Type: text/plain;
> 	charset="Windows-1252"
> Content-Transfer-Encoding: quoted-printable
> 
> I=92ve been thinking for quite a while about the
> Sisyphus.Impl =
> namespace.  As we add DataStore implementations, the
> current =
> implementation will force the inclusion of
> significant baggage.
> 
> =20
> 
> What do you think about changing the current
> implementation to something =
> like the following:
> 
> =20
> 
> Sisyphus.DataStore.Access
> 
> Sisyphus.DataStore.SqlClient
> 
> Sisyphus.DataStore.Oracle
> 
> =20
> 
> and so on=85.
> 
> =20
> 
> Each of these implementations could be stored in a
> separate dll, thereby =
> keeping the Oracle stuff from being pulled in when a
> programmer is only =
> interested in the Access.
> 
=== message truncated === 

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Scott, I think that you are absolutely right!
I had similar thoughts also and now I think it's the best time to do
this, because we are about to add OracleDataStore.
=20
Would you also take care of adding OracleDataStore?
Pascal RECCHIA emailed me two files - OracleDataStore.cs,
OracleIDGenerator.cs, but I hadn't time yet to look them through and
commit to CVS.
=20
I also think that we should eliminate references to Util from Core and
Impl, because they do not really use anything from Util.
If you don't mind, I can do it.
=20
As for runtime DataStore selection, the difference in implementation is
primarily due to their constructors. We can easily add DataStoreFactory
class, which will have overloaded methods for each DataStore:
public class DataStoreFactory {
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string
p_Database)
    public ISpfDataStore CreateSqlDataStore(string p_Server, string
p_Database, string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string
p_ConnectionString)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile,
string p_User, string p_Password)
    public ISpfDataStore CreateAccessDataStore(string p_DatabaseFile,
string p_User, string p_Password, bool p_Create)
    public ISpfDataStore CreateSqlDataStore(string p_ConnectionString)=20
    public ISpfDataStore CreateSqlDataStore(string p_Datasource)
    public ISpfDataStore CreateSqlDataStore(string p_Datasource, string
p_User, string p_Password)=20
}

Regards,
Vlad.
=20

-----Original Message-----
From: sis...@li...
[mailto:sis...@li...] On Behalf Of
Scott A. Pascoe
Sent: Wednesday, May 28, 2003 5:53 AM
To: sis...@li...
Subject: [Sisyphuspf-developers] RE: Thoughts about the Sisyphus.Impl
namespace



I=92ve been thinking for quite a while about the Sisyphus.Impl =
namespace.
As we add DataStore implementations, the current implementation will
force the inclusion of significant baggage.

=20

What do you think about changing the current implementation to something
like the following:

=20

Sisyphus.DataStore.Access

Sisyphus.DataStore.SqlClient

Sisyphus.DataStore.Oracle

=20

and so on=85.

=20

Each of these implementations could be stored in a separate dll, thereby
keeping the Oracle stuff from being pulled in when a programmer is only
interested in the Access.

=20

As an additional idea, I been thinking about the possibility of enabling
the DataStore to be selected at runtime, instead of compiletime.  One of
the issues here is the differences in implementations between the
various DataStores.  I=92m not sure right now, how we would make that
feature work.  Any ideas welcome=85.

=20

If I get a consensus of go on the change, I can begin working on the
idea.  Let me know what you guys think about these ideas --- am I full
of water or is this a good idea?

=20

Thanks,

=20

Scott Pascoe=20

I=92ve been thinking for quite a while about the Sisyphus.Impl =
namespace.  As we add DataStore implementations, the current =
implementation will force the inclusion of significant baggage.

=20

What do you think about changing the current implementation to something =
like the following:

=20

Sisyphus.DataStore.Access

Sisyphus.DataStore.SqlClient

Sisyphus.DataStore.Oracle

=20

and so on=85.

=20

Each of these implementations could be stored in a separate dll, thereby =
keeping the Oracle stuff from being pulled in when a programmer is only =
interested in the Access.

=20

As an additional idea, I been thinking about the possibility of enabling =
the DataStore to be selected at runtime, instead of compiletime.  One of =
the issues here is the differences in implementations between the =
various DataStores.  I=92m not sure right now, how we would make that =
feature work.  Any ideas welcome=85.

=20

If I get a consensus of go on the change, I can begin working on the =
idea.  Let me know what you guys think about these ideas --- am I full =
of water or is this a good idea?

=20

Thanks,

=20

Scott Pascoe=20

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.483 / Virus Database: 279 - Release Date: 5/19/2003
=20

Hi all!

I have some thoughts about the future of the project.

Today there is a demand for object persistence frameworks for .Net
But there exists very few frameworks.
I personally know about 2 commercial frameworks:

1) DeKlarit (http://www.deklarit.com/)
Its a powerful RAD tool and persistence library with tight integration
with Visual Studio.Net. (It costs $899)
It's last version 2.0 is very featurefull (according to description on
the website).

2) .net Persistence (http://www.objectpersistence.com/)
Its a simple persistence library. It's last version 1.1.0 costs $395.
It's quite similar to Sisyphus 1.2.9. It doesn't have advanced features
such as many-to-many relation etc.

There is only one open-source persistence framework and it's Sisyphus.
That was the reason why I used it and joined its development.
But as I see, there are few users and developers that are using
Sisyphus.
And things will not change to the better... Because Sisyphus will have
strong competitor in nearest future.

There are two primary competitors:
1) Microsoft. It's planning to release an object persistance framework
(named ObjectSpaces) together with next major version of .Net Framework.
See more details about it:
http://my.execpc.com/~gopalan/dotnet/object_spaces/object_spaces.html
http://hosting.msugs.ch/DotNetRox/articles/Art07.html

2) Open-source port of some popular Java persistance framework.
Such port for Hibernate has recently started and has good progress so
far.
http://sourceforge.net/projects/nhibernate/

Its obvious that Sisyphus will fail to compete with both of them.
So I am asking myself how do I want to be involved in Sisyphus and what
direction should the project follow.

Sisyphus has some advantages that can make it a good choice for some
projects.
One of such advantages is its modularity and modest size (comparing to
Hibernate for example).
This will enable anyone to modify project's sources to fit their needs.
(As I did with many-to-many relations). For the same reason (ease of
modifications) it has advantage over Microsoft libraries which will be
closed.

So what we need to do?
We should provide good comparison of Sisyphus and other frameworks.
We should ensure better possible compatibility with other persistance
frameworks. If we were trying to be compatible, users will feel
themselves safer using Sisyphus.
We should make some promotion of the project...

Here is my vision for the future of the project.
I personally would like to work on my contributions (many-to-many
mappings) to make them compatible to other frameworks. I'll look at
abovementioned frameworks and will try to match behavior and syntax used
for many-to-many relations closer to them.

I'm thinking on changing current syntax to something similar to
ObjectSpaces or Hibernate.
The following examples aren't very intuitive:
[SpfChildStorage(ForeignKey = "PersonDetailsID", IsReference = false)]
[SpfChildStorage(ChildType = typeof(Candidate), ForeignKey =
"CandidateID",
     ParentKey = "VacancyID", AssociateTable = "CandidateListMap")]

I think the core architecture is great and I just want to make my
contributions better, learning from other framework's.

Vlad.

Hi, Oliver!

> I am still uncertain about these things:
> It was the default behavior of the 1.2.9-version that 
> entities in child collections were owned by their parents
> (i.e. if order was deleted, so were
> all orderlines belonging to that order).
Yes, it is so.

> The default behavior seems now to have changed - if I delete 
> the parent entity, only reference entries in the association
> table get deleted. The child entities remain untouched.
Yes.

> My first guess was that the IsReference-switch does change 
> the behavior
> (reference vs. ownership), but that's not the case.

You are right. I fixed this behavior in CVS.
So IsReference can be set to both true and false for many-to-many
mappings.
The default value is false, which is inconsistent with previous approach
but is nessesary for compatibility with 1.2.9.

> So perhaps you can help me to get one SpfChildCollection that owns the
> children (as in 1.2.9) and another SpfChildCollection, that 
> only stores the references.
I've commited this to CVS.

Vlad.

Hi all,

=20

I=92ve been working on adding XML Documentation to the project.   So =
far, I=92ve gotten the built documentation for:

ISpfDataStoreBroker

ISpfEntityPersister

SpfDefaultEntityPersister

=20

I=92ve checked these into CVS.  The only updates are the =
documentation=97no code changes from my end.

=20

Please review the documentation, and refactor it to be effective.  If =
you wish to send me any changes, I=92ll gladly review them and commit =
them to CVS.

=20

Thanks,

=20

Scott Pascoe

=20

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003
=20

Hi, Oliver!

A created simple example for many-to-many association.
It's based on DemoApp from Sisyphus distribution.

New entity is implemented in WeeklyReport.cs
This is report entity that has m-m association with ReportEntry.

I modified WeeklyReportForm.cs to show how it can be used.
Look at PopulateGrid() method:
Instead of building datagrid source from reportEntries array directly, I
collect them in WeeklyReport object first. It then can be persisted as
usual SpfEntity. Note that you'll need to create tables yourself to
persist this object and it's relations.

If you need to add/remove individual Entries from WeeklyReport, you just
Add/Remove them from WeeklyReport.EntryList collection and then persist
WeeklyReport. Entries will be added/removed as relations in associate
table. You can get/set all entries at once by calling
WeeklyReport.EntryList.GetValues() or
WeeklyReport.EntryList.SetValues().

Hope this will help.
Please feel free to ask more questions.

Vlad.

> -----Original Message-----
> 
> Hi!
> 
> Thanks for your contributions. Would it be possible for you to 
> include an example (source code listing) to the mailing list of 
> how your changes are applied for a m-m association?
> I read your earlier postings, but a complete working example 
> would be better (at least for me...)
> 
> Thank you again.
> 
> Oliver.

I=92ve added the beginnings of a CHANGELOG in the same location as =
Spf.sln in CVS. =20

=20

I still have work to do on documenting the diffs from 1-2-9, but will =
continue working on that. =20

=20

I=92ve documented the AccessDataStore changes that I made tonight in =
this file, as well as notes in CVS.

=20

Thanks,

Scott

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003
=20

Hi All!

=20

I recently found out how to use ADOX to create an Access Database file =
from scratch.  I refactored the AccessDataStore contructor into two to =
enhance the functionality.

=20

The old way still fails if the file doesn=92t exist.  The new way will =
create the file if told to.

=20

Basically, the old calls looked like:

=20

ISpfDataStore ds =3D new =
AccessDataStore(=93c:\path\file.mdb=94,=94=94,=94=94) =20

=20

Where the first parameter has to exist.

=20

The new functionality is

=20

ISpfDataStore ds =3D new =
AccessDataStore(=93c:\path\file.mdb=94,=94=94,=94=94, true)

=20

The fourth parameter, if true causes the file to be created,  If false, =
the behavior is the same as the previous method.

=20

Thanks, Scott=20

=20


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 4/24/2003
=20

Hi Andrew

> Hi Vlad
> 
> Thanks for the emails! I've had a quick look through the .txt 
> files in your zip, but have not had a chance to experiment
> or look through the source yet. I have a few questions
> related to what you have done on the many-many work:-
> 
> You give an example of a Vacancy-Candidate relationship using 
> a "map" table to hold the foreign keys.
> Presumably this map record is automatically created 
> when the "Vacancy" is persisted?
Yes.

> Is it possible to access or modify this map record as an entity?
No.
Because Sisyphus doen't support entites with compound keys.
So if you has a table 
VacancyCandidateMap
VacancyID
CandidateID
You can't create entity VacancyCandidateMap because there is no key
column in this table, but a combination of two columns.
I proposed simple work-around for this as I will describe later. (See my
example for Candidate-Language relation.)

> Would I have to create a corresponding entity and create 
> a 1-many child collection for them?
No, you just have to add Candidate entities directly to
Vacancy.CandidateList.
Code sample:

Candidate c1 = new Candidate();
c1 = broker.Persist(c1);
Candidate c2 = new Candidate();
c2 = broker.Persist(c2);

Vacancy v = new Vacancy();
v.CandidateList.Add(c1);
v.CandidateList.Add(c2);
v = broker.Persist(v);

Entity doen't automatically save related objects. (Should it?)
It just saves the relation redords.

> I can think of situations where I would want a map record to 
> hold more than just the foreign keys (eg. the results of a Candidate's

> application to a Vacancy), and would therefore need a way
> to access and modify these records.
I had to solve such a situation for relation between candidates and
languages.
Each Candidate knows number of languages with certain 'KnowledgeLevel'.
CandidateLanguageMap:
CandidateID
LanguageID
Knowledge (int)

LanguageKnowledge entity is used as an intermediate entity to represent
the relation:

[SpfTypeStorage(
	TableName = "LanguageKnowledgeMap",
	IdFieldName = "LanguageID",
	PersisterType = typeof(SpfChildEntityPersister))]
public class LanguageKnowledge : SpfEntity
{
	[SpfFieldStorage(IsKey = true)]
	public Guid CandidateID;	
	public int Knowledge;
}

CandidateID field has attribute [SpfFieldStorage(IsKey = true)] that is
used by SpfChildEntityPersister to persist and retrieve entities with
compound primary key. I've writtent SpfChildEntityPersister specially to
support IsKey fields but I think it's code can be integrated into core
Sisyphus if we add IsKey support to it.

> (It would be nice if you could iterate through a many-many 
> child collection but specify whether you want to look at the
"associate"
> or the "map" entity!).
Using the above shown approach you will always iterate through the "map"
entity LanguageKnowledge, but you can add Candidate field to it to be
able to work with "associate" entity.

> Will the changes allow you to create more than one join 
> between the same two entities?
No.
Or maybe yes - with above shown approach. You just have to add one more
field with [SpfFieldStorage(IsKey = true)] attribute to have unique
primary key for "map" entity.

> I can think of some situations where this would be 
> possible (it would be like Vacancy "X" having two joins
> to Candidate "Y" - not a good example, but you get the point!).

> What if I want to traverse the relationship in the opposite 
> direction, i.e. look at a Candidate's children (vacancies)?
> Do I just create an SpfChildCollection like your example
> (but with the SpfChildStorage attributes - ParentKey,
> ForeignKey, AssociateTable, etc - defined the other way round)?
Yes.

> Does it support ordered many-many relations (ie. use of the 
> ChildPosition property of SpfChildStorage attribute)?
No.
> This "index field" would have to be stored in the map table of course.


Summing up, I should say that we need to discuss the implementation for
many-to-many and other types of relations, because I feel that my
current design is not perfect.

Please feel free to ask me more questions or give some suggestions - I'd
like to continue working on improving my code so it could finally be
merged into Sisyphus. (Unless any better solution is implemented.)

Vlad.

Hi all,
 
I checked out Spf1 from CVS and fixed it to compile.
It hasn't compiled "as is" because of SpfSqlDataTypeImpls.cs - this file
(written by me) isn't completed yet and shouldn't be included in the
project. (The same for SpfSProcEntityPersister.cs).
I committed my changes back to CVS.
 
I think that we need some things to be done to move further with
Sisyphus:
1) All developers should subscribe to
sis...@li...
2) We need to add ChangeLog file to the project and log all our changes
there, starting from original 1.2.9 release.
If there are no objections, I'd like to ask Scott to write down all
changes between current CVS version and 1.2.9
 
For the current CVS version I have couple of questions:
1) What is SpfEntityBroker and all related files?
2) Why are SpfDataStoreBroker.cs and ErrorHandler.cs not included in
Core.csproj
 
My plans are to work on merging my changes to SPF and then help
improving website, documentation and other bits of this project.
 
I'm going to share my TODO list as soon as all of us are subscribed to
the mailing list.
I think it would be great if all of us tell others their plans.
 
Vlad.