Re: #liveDB server, research and upcoming webinar on In-Memory Database Systems

Not very fond of "engine" myself...
In my world, engine is a driving force. Most prevalence layers are not.
Must not be tempted to use fancy words for marketing purposes.
Den 10 feb 2012 14:31 skrev "Felipe Cruz" <[email protected]>:

>
>
> 2012/2/10 Robert Friberg <[email protected]>
>
>> Felipe,
>>
>> > Objects in memory + prevalence tool = prevalent system (or layer)
>>
>> *Objects* in memory?
>> Prevalence doesn't require objects. The system in memory could have any
>> representation. The same goes for the transaction journal, transactions can
>> have any representation as long as they can be reinterpreted to restore the
>> system.
>>
>
> agreed :)
>
>
>> Tool?
>> Engine!
>>
>
> agreed
>
>
> Layer?
>> What if the architecture is component or service-oriented?
>>
>
> still a layer to me..
>
> This post is really cool..
>
> And I'm with Klaus.. I've saw people creating prevalent systems (some very
> simple.. but still) and giving other names..
>
> Maybe we can create a wiki about prevalence.. http://prevalence.ioThere's a lot of misconception about prevalence engines and styles
>
>
>
>
>>
>> We use the term Model for the in memory database and if I recall correct,
>> prevayler uses Transaction.executeTransaction(Object system). The parameter
>> name "system" is generic enough but could be confused with the "Prevalent
>> System" which includes the engine (tool) according to your definition. I
>> think the original intention was:
>>
>>        Prevalent system + engine = prevalence layer
>>
>> Also, I'm uncomfortable with Transaction, in the rdbms world queries are
>> also transactions. Instead we say Command, CommandWithResults and Query
>> which all inherited abstract Transaction.
>>
>> Our execute was Command.Execute(Model graph), currently it is
>> Command.Execute(Model model).
>> We changed from graph because it implies objects (object graph).
>>
>> I'll can elaborate on why we chose Model but I'll save that for later
>> post.
>>
>>
>> Robert Friberg
>> 0733-839080
>> http://livedb.devrex.se
>> http://livedomain.codeplex.com
>> http://devrex.se
>> http://www.linkedin.com/in/robertfriberg
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> To unsubscribe go to the end of this page:
>> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
>> _______________________________________________
>> "Databases in Memoriam" -- http://www.prevayler.org
>>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> To unsubscribe go to the end of this page:
> http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
> _______________________________________________
> "Databases in Memoriam" -- http://www.prevayler.org
>
>

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org