Moe is a databse persistency framework based which uses Magritte and Roe for persisting objects to PostgreSQL db's. The one novel thing about it (and I am sure I can't be the first person to have thought of it) is that, instead of serializing contained objects to the db column for that object, it stores the id of any embedded/persisted object in the db column for that object and rebuilds the object with its embeddded objects on reload. It works for embedded collections as well writing an integer array to the db column to represent the collection in the db. Its a relatively simple and somewhat naive framwork written by a newbie :) I like to think of it as an Inactive Record Pattern in that Active Record Pattern requires the objects to (somewhat) model the database, and requires you to implement the database features (like foreign keys) in the object model. The philosophy of Moe is to use the db as a mirror of the model objects. Where there is a collection in the model the db should also have a collection, etc. I don't use any kind of foreign key relations in my objects so I wht should I bother with them at all. Best of all, it is all implemented using Magritte meta descriptons.
Along with this the Postgres package has been modified to include integer array support. I also needed to implement money columns so I added support for the money type in postgres and used Avi Bryants Money package from squeaksource to model money types. Support has been added for reading a string representation of money replete with Locale defined separators and decimals. The money implementation required that I write a new Magritte description so Magritte-Money is now available in the Magritte-Addons project. Again, to use this you will need to load the Money package. The following packages will be required to use Moe: PostgresV2 Roe Magritte-Roe and incidentally Money and Magritte-Money (you can get away with not using Money by using the previous version of PostgresV2) Lastly, I have always been dissappointed in the strictly vertical rendering of Magritte described objects and decided to implement a renderer that would give them a more horizontal feel. MARowRenderer will group your descriptions based on their priorities. Priorities 1-9 will render on one row, 10-19 on the next row, 20-29 on the next row and so on. Its a little kludgy, and the algorithm needs some work to make it more efficient, but it works well. Column spans are also calculated so rows do not have to have the same number of elements to look good. If you've ever wished you could get the person's Last Name, First Name and Middle Name to render on one row, and the address fields to render on their own row etc, this will do the trick. Simply implement descriptionContainer on your object to return MARowContainer and voila! I hope the community finds some of this stuff useful. John McKeon -- http://jmck.seasidehosting.st _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Hi john
Thanks. I think that we should get more of these Magritte driven building blocks :) Stef On Jul 16, 2009, at 4:43 AM, John McKeon wrote: > Moe is a databse persistency framework based which uses Magritte and > Roe for persisting objects to PostgreSQL db's. The one novel thing > about it (and I am sure I can't be the first person to have thought > of it) is that, instead of serializing contained objects to the db > column for that object, it stores the id of any embedded/persisted > object in the db column for that object and rebuilds the object with > its embeddded objects on reload. It works for embedded collections > as well writing an integer array to the db column to represent the > collection in the db. Its a relatively simple and somewhat naive > framwork written by a newbie :) I like to think of it as an Inactive > Record Pattern in that Active Record Pattern requires the objects to > (somewhat) model the database, and requires you to implement the > database features (like foreign keys) in the object model. The > philosophy of Moe is to use the db as a mirror of the model objects. > Where there is a collection in the model the db should also have a > collection, etc. I don't use any kind of foreign key relations in my > objects so I wht should I bother with them at all. Best of all, it > is all implemented using Magritte meta descriptons. > > Along with this the Postgres package has been modified to include > integer array support. > > I also needed to implement money columns so I added support for the > money type in postgres and used Avi Bryants Money package from > squeaksource to model money types. Support has been added for > reading a string representation of money replete with Locale defined > separators and decimals. > > The money implementation required that I write a new Magritte > description so Magritte-Money is now available in the Magritte- > Addons project. Again, to use this you will need to load the Money > package. > > The following packages will be required to use Moe: > PostgresV2 > Roe > Magritte-Roe > and incidentally Money and Magritte-Money > (you can get away with not using Money by using the previous version > of PostgresV2) > > Lastly, I have always been dissappointed in the strictly vertical > rendering of Magritte described objects and decided to implement a > renderer that would give them a more horizontal feel. MARowRenderer > will group your descriptions based on their priorities. Priorities > 1-9 will render on one row, 10-19 on the next row, 20-29 on the next > row and so on. Its a little kludgy, and the algorithm needs some > work to make it more efficient, but it works well. Column spans are > also calculated so rows do not have to have the same number of > elements to look good. If you've ever wished you could get the > person's Last Name, First Name and Middle Name to render on one row, > and the address fields to render on their own row etc, this will do > the trick. Simply implement descriptionContainer on your object to > return MARowContainer and voila! > > I hope the community finds some of this stuff useful. > John McKeon > > > > -- > http://jmck.seasidehosting.st > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by John McKeon
John: excellent news!! I really like the different persistence alternatives we have in Squeak :)
A couple of questions: 1) Which is the difference between Moe and Roe. I ask because here: http://www.seaside.st/documentation/persistence#185450097 I saw Roe. 2) Which are the advantages and disadvantages of Moe over other Magritte related stuff like Magritte-RDB for example ? 3) Is this project similar to SqueakSave? http://www.hpi.uni-potsdam.de/hirschfeld/projects/sqsave/index.html Thanks and congratulations for the work! ps: if you have to user another database instead of postgres, you know there is SqueakDBX ;) On Thu, Jul 16, 2009 at 1:43 AM, John McKeon <[hidden email]> wrote: Moe is a databse persistency framework based which uses Magritte and Roe for persisting objects to PostgreSQL db's. The one novel thing about it (and I am sure I can't be the first person to have thought of it) is that, instead of serializing contained objects to the db column for that object, it stores the id of any embedded/persisted object in the db column for that object and rebuilds the object with its embeddded objects on reload. It works for embedded collections as well writing an integer array to the db column to represent the collection in the db. Its a relatively simple and somewhat naive framwork written by a newbie :) I like to think of it as an Inactive Record Pattern in that Active Record Pattern requires the objects to (somewhat) model the database, and requires you to implement the database features (like foreign keys) in the object model. The philosophy of Moe is to use the db as a mirror of the model objects. Where there is a collection in the model the db should also have a collection, etc. I don't use any kind of foreign key relations in my objects so I wht should I bother with them at all. Best of all, it is all implemented using Magritte meta descriptons. _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Thu, Jul 16, 2009 at 9:37 AM, Mariano Martinez Peck <[hidden email]> wrote: John: excellent news!! I really like the different persistence alternatives we have in Squeak :) Its not different. It *uses* Roe. Roe is the the framework that talks to a postgres db (generates the SQL). MAMappedObject in Magritte-Roe connects Magritte to Roe. You implement #tableName on the class side of your model. and send #sqlColumnName: in the descriptions of the fields you want to store in the db. Then you store the object in the db by sending #save. Moe builds on these two building blocks. It lets you describe objects within objects that you want to persist to
the db, and then persists them by storing integer ids only. Those embedded objects are expected to be stored in another table and can be loaded into the containing object using the contained object's id.
Disadvantages: The persisted objects must be subclasses of MOEmbeddedObject that is one downside. Also you cannot recursively embed objects. This kind of thing can be insidious so you have to be careful with what you describe as an embedded object/collection. Moe is only meant to make the db mirror your application data. Redundant storage only. It's very simple. Advantages: Its *very* simple :)
No way. That looks pretty awesome, though. I have to check it out..
Thanks Mariano
BTW it could use a few more tests :)
-- http://jmck.seasidehosting.st _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> Disadvantages:
> The persisted objects must be subclasses of MOEmbeddedObject that is > one downside. John why? May be just a trait would be nice since you could plug your layer in any domain objects. I was just planning to do a stupid traits to save magritte described object in XML. I was planning to do the same with SandStone: turning the root class in a trait and get free from framework tyranny. > Also you cannot recursively embed objects. This kind of thing can be > insidious so you have to be careful with what you describe as an > embedded object/collection. > Moe is only meant to make the db mirror your application data. > Redundant storage only. > It's very simple. > > Advantages: > Its *very* simple :) > > > 3) Is this project similar to SqueakSave? http://www.hpi.uni-potsdam.de/hirschfeld/projects/sqsave/index.html > > No way. That looks pretty awesome, though. I have to check it out.. > > ps: if you have to user another database instead of postgres, you > know there is SqueakDBX ;) > > BTW it could use a few more tests :) Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Thu, Jul 16, 2009 at 2:15 PM, stéphane ducasse <[hidden email]> wrote:
I have never looked into Traits I am still fairly new to Smalltalk. One can only digest so many frameworks in a day :) But really I was just working with Magritte to get a more intimate understanding of it. Saw that Magritte-Roe gives us very easy connectivity to PostgreSQL whilst keeping all that other Magritte meta-description goodness and I just extended it a little to suit what I saw as a need. I will put Traits on my "to look into" list. Cheers John
-- http://jmck.seasidehosting.st _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Jul 16, 2009, at 9:48 PM, John McKeon wrote: > > > On Thu, Jul 16, 2009 at 2:15 PM, stéphane ducasse <[hidden email] > > wrote: > Disadvantages: > The persisted objects must be subclasses of MOEmbeddedObject that is > one downside. > > John why? > May be just a trait would be nice since you could plug your layer in > any domain objects. > I was just planning to do a stupid traits to save magritte described > object in XML. > I was planning to do the same with SandStone: turning the root class > in a trait and get free > from framework tyranny. > > I have never looked into Traits I am still fairly new to Smalltalk. > One can only digest so many frameworks in a day :) Lol > But really I was just working with Magritte to get a more intimate > understanding of it. Saw that Magritte-Roe gives us very easy > connectivity to PostgreSQL whilst keeping all that other Magritte > meta-description goodness and I just extended it a little to suit > what I saw as a need. > > I will put Traits on my "to look into" list. > > Cheers > John > > > > Also you cannot recursively embed objects. This kind of thing can be > insidious so you have to be careful with what you describe as an > embedded object/collection. > Moe is only meant to make the db mirror your application data. > Redundant storage only. > It's very simple. > > Advantages: > Its *very* simple :) > > > 3) Is this project similar to SqueakSave? http://www.hpi.uni-potsdam.de/hirschfeld/projects/sqsave/index.html > > No way. That looks pretty awesome, though. I have to check it out.. > > ps: if you have to user another database instead of postgres, you > know there is SqueakDBX ;) > > BTW it could use a few more tests :) > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > > -- > http://jmck.seasidehosting.st > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by John McKeon
On Thu, Jul 16, 2009 at 3:51 PM, John McKeon <[hidden email]> wrote:
Ok, thanks for the explanation! Is there a webpage/documentation or something about this project?
It has been already discussed :)
yes, it seems to be.
Yes. I send a couple of email to them because I really find it very useful. At least for me it seems to be (I couldn't test it yet) an excellent situation when: - Small/middle applications. I don't believe big applications can have tables and all that stuff autogenerated. - If you want or need (the client makes you) a RDBMS (this is very common here) - You don't want to spend time doing mappings (as you need in Glorp for example)
I didn't understood what you wanted to say hahaha.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Thu, Jul 16, 2009 at 4:52 PM, Mariano Martinez Peck <[hidden email]> wrote:
No What do you want for nothin? lol I need to write more tests (i've already found some bugs with the changes I made to Money) once i am satisfied with that i will try to put together an example)
I thought i heard yousay somewhere that you are writing all the tests for SqueakDBX., i could be mistaken
-- http://jmck.seasidehosting.st _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On Thu, Jul 16, 2009 at 9:16 PM, John McKeon <[hidden email]> wrote:
hehehehee
Maybe you are talking about a IRC talk we have in IRC with another guy who was telling me to do some Squeak tests. I told him that I do tests for my projects and give an example of SqueakDBX. Actually these tests are from the beginning, I am not doing right now. Furthermore, some of them were doing TDD :)
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Free forum by Nabble | Edit this page |