[Seaside] Persistence in VW

[Alan Knight]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20071213/9d440f4d/attachment.htm