--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 05, 2002 at 12:31:17AM +0900, David Corbin wrote:

> Well, it might from my original description.  I'm not sure how if it=20
> handles multiple references to the same object.  Regardless,  I've=20
> realized I need more flexibility than that really offers.   I don't=20
> actually want to load *all* the objects up front.   I want to load a=20
> core-set of objects, and then load others "on-demand".  Ideally, these=20
> latter ones would even get dropped from memory if not used in a certain=
=20
> amount of time, though that may not be required.

I'm on the way to write some persistance layer at the moment. An overal
design exists. At the time writing this I'm hassling with Mixins in Ruby
(as a watchful read of this list might have noticed). Following are my
design goals:

* Make the persistence engine pluggable, so we can have
  InMemoryPersistance, DB-Persitence, XML or file persistance.

* Build the framewort in a way that the business object aren't coupled
  to the persistence mechanism; this will simplify testing e.g.

* Make use of rubys meta programming capability to archive this.

Currently, my design is like this:

* A Mixin provides a "persist(*ids)" class method which make a given id
  persitent. The perist method implements accessors to the given ids
  which simply call a read or write method on a Persistor
  Implementation. It passed to it the instace, the attribute id and the
  value.

* The Mixin provides also a method "each" which fetches references to all
  persistet classes from the persistor.

Open issues:

* The persistor should return only instances or children of the class which=
=20
  calls request objects on behalf of the method "each".

Current coding look like:


require 'persist'

class Person
	# by default Persist uses a hash based Persistor
	include Persist

	persist :firname, :lastname   # this creates accessor proxy methods

	def initialize(first, last)
		firstname=3Dfirst
		lastname=3Dlast
	end
end

p1 =3D Person.new("Donald", "Duck");   =20
p2 =3D Person.new("Daisy", "Duck");

puts p1.lastname                        # calls p2.persistor.read(p2, "Dais=
y")
all =3D Person.each                       # calls p2.persistor.each


Any ideas or improvements are welcome. As soon as my code is stabilized
and working with a rough DBI implementation I will make it public.

My $0.02,
	-billy.

--=20
Meisterbohne       S=F6flinger Stra=DFe 100          Tel: +49-731-399 499-0
   eL=F6sungen       89077 Ulm                     Fax: +49-731-399 499-9

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JIqsfBriNoqItSYRAjviAJoDaA93eqYsD9heA0kcE3o8wPHVTgCfTuTQ
384prV56g7ooeIFD8elLPDo=
=Tc3L
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--
On Fri, Jul 05, 2002 at 12:31:17AM +0900, David Corbin wrote:

> Well, it might from my original description.  I'm not sure how if it=20
> handles multiple references to the same object.  Regardless,  I've=20
> realized I need more flexibility than that really offers.   I don't=20
> actually want to load *all* the objects up front.   I want to load a=20
> core-set of objects, and then load others "on-demand".  Ideally, these=20
> latter ones would even get dropped from memory if not used in a certain=
=20
> amount of time, though that may not be required.

I'm on the way to write some persistance layer at the moment. An overal
design exists. At the time writing this I'm hassling with Mixins in Ruby
(as a watchful read of this list might have noticed). Following are my
design goals:

* Make the persistence engine pluggable, so we can have
  InMemoryPersistance, DB-Persitence, XML or file persistance.

* Build the framewort in a way that the business object aren't coupled
  to the persistence mechanism; this will simplify testing e.g.

* Make use of rubys meta programming capability to archive this.

Currently, my design is like this:

* A Mixin provides a "persist(*ids)" class method which make a given id
  persitent. The perist method implements accessors to the given ids
  which simply call a read or write method on a Persistor
  Implementation. It passed to it the instace, the attribute id and the
  value.

* The Mixin provides also a method "each" which fetches references to all
  persistet classes from the persistor.

Open issues:

* The persistor should return only instances or children of the class which=
=20
  calls request objects on behalf of the method "each".

Current coding look like:


require 'persist'

class Person
	# by default Persist uses a hash based Persistor
	include Persist

	persist :firname, :lastname   # this creates accessor proxy methods

	def initialize(first, last)
		firstname=3Dfirst
		lastname=3Dlast
	end
end

p1 =3D Person.new("Donald", "Duck");   =20
p2 =3D Person.new("Daisy", "Duck");

puts p1.lastname                        # calls p2.persistor.read(p2, "Dais=
y")
all =3D Person.each                       # calls p2.persistor.each


Any ideas or improvements are welcome. As soon as my code is stabilized
and working with a rough DBI implementation I will make it public.

My $0.02,
	-billy.

--=20
Meisterbohne       S=F6flinger Stra=DFe 100          Tel: +49-731-399 499-0
   eL=F6sungen       89077 Ulm                     Fax: +49-731-399 499-9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9JIqsfBriNoqItSYRAjviAJoDaA93eqYsD9heA0kcE3o8wPHVTgCfTuTQ
384prV56g7ooeIFD8elLPDo=
=Tc3L
-----END PGP SIGNATURE-----