Re: [Pharo-users] SandstoneDB, Fuel - Contexts must only be created with newForMethod:
I'm using Pharo 1.3. The Fuel versions are: Fuel-MartinDias.338 FuelTests-MartinDias.84 160 of 160 tests pass. The config version is: ConfigurationOfFuel-MartinDias.65 I loaded the #stable version for 1.3. #sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext. The Sandstone DB versions are SandstoneDb-RamonLeon.144 SandstoneDbTests-RamonLeon.10
On 09/09/2011 10:36 AM, Paul DeBruicker wrote:
#sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext.
Because SandstoneDb isn't meant to save special objects like classes, blocks, or method context's, it's meant to save plain old Smalltalk data objects from your domain the same way you'd use a relational database. It's a simple active record data store for quick prototyping based on serialized files, not a full blown object database that can save every possible object type.
And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I get the same error if, when using the same image, in a workspace I change the SDSerializer to the SDSmartRefStreamSerializer and try again.
Correct. Now, apparently fuel might be able to save some of those special objects like blocks or classes, but SandstoneDb will throw an error if you attempt to save a class regardless of what the serializer supports. -- Ramon Leon http://onsmalltalk.com
On Fri, Sep 9, 2011 at 7:48 PM, Ramon Leon <ramon.leon@allresnet.com> wrote:
On 09/09/2011 10:36 AM, Paul DeBruicker wrote:
#sandstoneDeepCopyVisits: is calling basicNew: on the class MethodContext.
Because SandstoneDb isn't meant to save special objects like classes, blocks, or method context's, it's meant to save plain old Smalltalk data objects from your domain the same way you'd use a relational database. It's a simple active record data store for quick prototyping based on serialized files, not a full blown object database that can save every possible object type.
Be careful with SortedCollection instances for example ;)
And I'd guess that it's not a Fuel issue but a SandstoneDB issue because I
get the same error if, when using the same image, in a workspace I change the SDSerializer to the SDSmartRefStreamSerializer and try again.
Correct. Now, apparently fuel might be able to save some of those special objects like blocks or classes
indeed. Contexts, classes, CompiledMethod, etc...
, but SandstoneDb will throw an error if you attempt to save a class regardless of what the serializer supports.
-- Ramon Leon http://onsmalltalk.com
-- Mariano http://marianopeck.wordpress.com
On 09/09/2011 10:50 AM, Mariano Martinez Peck wrote:
Be careful with SortedCollection instances for example ;)
Yes, SandstoneDb can't store those because of the sort block, store an OrderedCollection and sort it on the fly when you need it. Maybe I'll add support since Fuel supports it, but I have a feeling it's a can of worms I don't want to open for lack of commitment at the moment. -- Ramon Leon http://onsmalltalk.com
On Fri, Sep 9, 2011 at 7:55 PM, Ramon Leon <ramon.leon@allresnet.com> wrote:
On 09/09/2011 10:50 AM, Mariano Martinez Peck wrote:
Be careful with SortedCollection instances for example ;)
Yes, SandstoneDb can't store those because of the sort block, store an OrderedCollection and sort it on the fly when you need it. Maybe I'll add support since Fuel supports it, but I have a feeling it's a can of worms I don't want to open for lack of commitment at the moment.
Yes, basically because it is likely you will end up serializing a whole stack. If you follow a BlockClosure sender sender sender blah blah home home blah blah yes...it is complicated.
-- Ramon Leon http://onsmalltalk.com
-- Mariano http://marianopeck.wordpress.com
On 09/10/2011 02:23 AM, Mariano Martinez Peck wrote:
Yes, basically because it is likely you will end up serializing a whole stack. If you follow a BlockClosure sender sender sender blah blah home home blah blah yes...it is complicated.
Hence my advice when attempting to save blocks in SandstoneDb... don't do that. Databases are for data, not for suspended execution environments like closures. -- Ramon Leon http://onsmalltalk.com
participants (3)
-
Mariano Martinez Peck -
Paul DeBruicker -
Ramon Leon