Data Sources
Locked
 
|
I know nothing about databases. Okay, I take that back -- I know a
little, but not much. Nevertheless, it seems we need a way to talk to these things from the SiteRegistry and from our Resources. The SiteRegistry needs someplace to get its sites from, and the individual resources (e.g. a Wiki) need to get their content data from somewhere. I'd like to support both of these needs within the same framework if possible. Aleksander proposed a system that I didn't fully understand (see first line). If somebody else who knows databases better can respond to his message, please do. It seemed primarily focused on fetching resources out of a data store. So I'd like to take his proposal and tweak it just a little. Aleksander, maybe you can respond here and fill in the gaps in my logic. No matter what sort of back-end data store we're using, we'll want an object that presents an interface to it. That object should be useful to Resources and to the SiteRegistry. Aleksander proposed a name of ResourceSource, but I'd prefer the name DataSource precisely because it will be used to fetch Resources, customers, Wiki page contents, or whatever. For what the SiteRegistry needs, we'd need only implement DataSource>>sites. A GemStoneDataSource would hand back a proxy to a collection of sites, which the SiteRegistry could then #add: to itself, starting the appropriate servers as necessary. An XMLDataSource could create new Sites (and their appropriate child resources) from the definition in a flat file. A PostgreSQLDataSource could fetch the site definitions from a table and build up Sites accordingly. One advantage that this affords is the ability to add someething like Steve Waring's SiteScripts. Just subclass the data source of your liking and change the way it builds sites, e.g. sites ^self allMyCustomers collect: [:each | self mySpecialSiteFor: each] SiteRegistry will then be told to configure himself from a data source. For resource-specific content data, we'd add a DataSourceResource that becomes the parent of any Resource (or tree of Resources) that needs to get at external data in order to respond to a Request. This Resource does nothing more than associate a DataSource with each request that passes through it. The child resources are then free to use the data when constructing a response. DataSources will understand messages that make sense according to the type of DataSource they represent. A PostgreSQL data source might understand things like #tableAt: (returns a Table that understands #rowAt:, which returns objects representing the rows). An XMLDataSource might understand messages related to element access. Resources use these methods to fetch the data they're looking for. If an application wants a more concise API (something like #wikiPageNamed:), the appropriate DataSource can be subclassed again. With APIs like this, Resources could be completely unaware of whether they were getting their data from a file, a relational database, or an OODB. Feedback encouraged. Ken |
|
|
Ken,
Joe will surelly help me here a lot :) A beauty od ODMS-ses like Gemstone is transparency. That means that you actually don't need to do anything to make your objects persistent. It's almost the same as image snapshot. That's the reason why I see image snapshot as persistence type nr1, because ODMS persistence as nr2 is then simple to achieve. And for image (and ODMS) persistence we don't need to introduce anything new. What Aleksander and me are proposing is some nice way to do settings in Resources (specially in Site). Cconfiguration from sites.cnf should be in such settings (specially ip, port, hostname and like). Configuration of Resource hierarchy is done by default dynamicaly at runtime and made persistent transparently in image (and ODMS). All we need is just to (optionaly) introduce some mechanism to put configuration in file like sites.cnf and here your proposal comes into light again. But optional, not needed in core Swazoo. Actually just loading another parcel should extend Swazoo for such configuration/persistence. Janko Ken Treis wrote: > I know nothing about databases. Okay, I take that back -- I know a > little, but not much. > > Nevertheless, it seems we need a way to talk to these things from the > SiteRegistry and from our Resources. The SiteRegistry needs someplace > to get its sites from, and the individual resources (e.g. a Wiki) need > to get their content data from somewhere. I'd like to support both of > these needs within the same framework if possible. > > Aleksander proposed a system that I didn't fully understand (see first > line). If somebody else who knows databases better can respond to his > message, please do. It seemed primarily focused on fetching resources > out of a data store. > > So I'd like to take his proposal and tweak it just a little. > Aleksander, maybe you can respond here and fill in the gaps in my logic. > > No matter what sort of back-end data store we're using, we'll want an > object that presents an interface to it. That object should be useful > to Resources and to the SiteRegistry. Aleksander proposed a name of > ResourceSource, but I'd prefer the name DataSource precisely because > it will be used to fetch Resources, customers, Wiki page contents, or > whatever. > > For what the SiteRegistry needs, we'd need only implement > DataSource>>sites. A GemStoneDataSource would hand back a proxy to a > collection of sites, which the SiteRegistry could then #add: to > itself, starting the appropriate servers as necessary. An > XMLDataSource could create new Sites (and their appropriate child > resources) from the definition in a flat file. A PostgreSQLDataSource > could fetch the site definitions from a table and build up Sites > accordingly. > > One advantage that this affords is the ability to add someething like > Steve Waring's SiteScripts. Just subclass the data source of your > liking and change the way it builds sites, e.g. > > sites > ^self allMyCustomers collect: [:each | self mySpecialSiteFor: each] > > SiteRegistry will then be told to configure himself from a data source. > > For resource-specific content data, we'd add a DataSourceResource that > becomes the parent of any Resource (or tree of Resources) that needs > to get at external data in order to respond to a Request. This > Resource does nothing more than associate a DataSource with each > request that passes through it. The child resources are then free to > use the data when constructing a response. > > DataSources will understand messages that make sense according to the > type of DataSource they represent. A PostgreSQL data source might > understand things like #tableAt: (returns a Table that understands > #rowAt:, which returns objects representing the rows). An > XMLDataSource might understand messages related to element access. > Resources use these methods to fetch the data they're looking for. > > If an application wants a more concise API (something like > #wikiPageNamed:), the appropriate DataSource can be subclassed again. > With APIs like this, Resources could be completely unaware of whether > they were getting their data from a file, a relational database, or an > OODB. > > Feedback encouraged. > > > Ken > > > _______________________________________________ > Swazoo-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/swazoo-devel > |
|
|
Janko Mivsek wrote:
> And for image (and ODMS) persistence we don't need to introduce > anything new. What Aleksander and me are proposing is some nice way to > do settings in Resources (specially in Site). Cconfiguration from > sites.cnf should be in such settings (specially ip, port, hostname and > like). Configuration of Resource hierarchy is done by default > dynamicaly at runtime and made persistent transparently in image (and > ODMS). Okay, I've probably misunderstood what you've been talking about. Are you saying that you would save ip, port, and hostname information in a sites.cnf file, but everything else would be stored in GS (or in the image)? A site is defined by several things, including 1 or more SiteIdentifiers (ip/port/hostname) and its child resources. It seems that you could store all of your sites entirely within GS. Or are you talking about something else when you say "Settings"? Please explain. Ken |
|
|
Hi Ken,
Tommorow I will start preparing Swazoo for connection to Gemstone. It seems that's better to explain persistency by example. And we need that anyway. The biggest change will be introduction of accessors to all instvars. This will be quite an undertaking but we need it to properly make Swazoo persistent in most cases. I will explain that in next e-mail. Janko Ken Treis wrote: > Janko Mivsek wrote: > >> And for image (and ODMS) persistence we don't need to introduce >> anything new. What Aleksander and me are proposing is some nice way >> to do settings in Resources (specially in Site). Cconfiguration from >> sites.cnf should be in such settings (specially ip, port, hostname >> and like). Configuration of Resource hierarchy is done by default >> dynamicaly at runtime and made persistent transparently in image (and >> ODMS). > > > Okay, I've probably misunderstood what you've been talking about. Are > you saying that you would save ip, port, and hostname information in a > sites.cnf file, but everything else would be stored in GS (or in the > image)? > A site is defined by several things, including 1 or more > SiteIdentifiers (ip/port/hostname) and its child resources. It seems > that you could store all of your sites entirely within GS. > > Or are you talking about something else when you say "Settings"? > Please explain. > > > Ken > > > |
«
Return to Swazoo
|
1 view|%1 views
| Free forum by Nabble | Edit this page |