[Seaside] Persistence in VW

[Oleg Richards]

Alan Knight-2 wrote:
> 
> Sure. It should (hopefully) be fairly easy to use, although if you're
> completely new to Glorp it probably can get interesting.
> 
> Subclass your classes from ActiveRecord. Then use
> ActiveRecordDescriptorSystem, or your own subclass of it, as the system,
> and log in. If you use the main class, it'll try to use all subclasses of
> ActiveRecord. If you make your own subclass you can implement
> #defaultRootClass to make it just be subclasses of your own abstract
> superclass (which it expects to be a subclass of ActiveRecord).
> 
> If you've named your classes according to the generally Ruby on Rails-ish
> conventions, which is to say that the Customer class corresponds to the
> CUSTOMERS table (or the CUSTOMER table, it's not all that fussy), then it
> should try to generate descriptors for that automatically. It'll do a good
> deal better if your foreign key fields are identified as such in the
> database. For parts that it doesn't get right, or at all, you can
> implement the normal Glorp methods like #descriptorForMyClassName:, but
> you should only have to give it the information for the mappings it didn't
> get right in the first place.
> 
> There are some simple examples in the GlorpActiveRecordTests package. Once
> it's mapped, then you can do a number of things by sending messages to the
> objects or their classes that would typically require you to use the Glorp
> session. e.g. aClass findWhere:, anObject save, etc.
> 
> At 12:57 PM 12/12/2007, Oleg Richards wrote:
> 
>>Thank you Alan!
>>
>>I will look at this classes. I need a little help with ActiveRecord? Can
you
>>show me how to use it? I understand that i should inherit all my models
from
>>AR class, but what next. Should i execute something in workspace? And how
to
>>attach session  to active record? 
>>
>>
>>
>>
>>
>>Alan Knight-2 wrote:
>>> 
>>> Inheritance is always rather tricky against a relational database,
>>> because
>>> the concept really isn't there, so you have to map it into some
>>> compromise, trading off space, query time, and flexibility. Glorp
>>> supports
>>> two different strategies for this, which we call horizontal and
>>> filtered.
>>> Filtered inheritance means all instances are stored in one bit table,
>>> and
>>> there's a field which indicates which type this row represents. This is
>>> efficient to query, but wastes spaces. Horizontal is where each subclass
>>> is represented by an entirely separate table. This is more likely if
>>> you're trying to impose an inheritance hierarchy on an existing
>>> database,
>>> and minimizes storage, but makes querying more complex. Some kinds of
>>> queries can be inefficient. You'd want to look at the TypeResolver class
>>> and its subclasses. In the Glorp tests, GlorpInheritanceDescriptorSystem
>>> has some examples.
>>> 
>>> By comparison, storing integers and dictionaries is pretty easy :-) If
>>> you
>>> want both key and value to be simple types, then you need a table
>>> somewhere to store them. If the value is an object, you can either have
>>> the key be part of the value's table, or in a link table.
>>> GlorpDictionaryMappingTest and GlorpEncyclopediaDescriptorSystem have
>>> examples.
>>> 
>>> Neither of those things is likely to work automatically with the
>>> GlorpActiveRecord code, you'll likely have to write out the mappings.
>>> But
>>> part of the point of the way GlorpActiveRecord is done is that you can
>>> let
>>> the parts that are easy get built automatically and only have to specify
>>> the tricky parts.
>>> 
>>> 
>>> 
>>
>>-- 
>>View this message in context:
http://www.nabble.com/Persistence-in-VW-tp14283675p14300415.html
>>Sent from the Squeak - Seaside mailing list archive at Nabble.com.
>>
>>_______________________________________________
>>seaside mailing list
>>seaside at lists.squeakfoundation.org
>>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> --
> Alan Knight [|], Cincom Smalltalk Development
> knight at acm.org
> aknight at cincom.com
> http://www.cincom.com/smalltalk
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> 

Thank you!

I will give it try. Can you explain me how to deal with logins? I ve read
articlr from Ramon about glorp sessions pool. But its for seaside and i am
interested in workspace or in global variable. 

Should i create tables first? Or activerecord wil create them?

-- 
View this message in context: http://www.nabble.com/Persistence-in-VW-tp14283675p14325085.html
Sent from the Squeak - Seaside mailing list archive at Nabble.com.