[Esug-list] [squeak-dev] [ANN] ESUG supports once againSqueakDBX

Carlos Crosetti carlos.crosetti at mostar.com.ar
Sat Mar 5 01:47:44 UTC 2011

My 10 cents to the SqueakDBX list of actions......

Long time ago, when I learnt about the VW UI Builder, I attempted to run an existing sample code that was basically a dataset widget browsing a collection of objects, and then I wrote some code to make them persistent using ObjectLens and Oracle.

Later on time, I would say 12+ years later, I learnt about GLORP and wrote a morphic-based dialog to do the most simple CRUD model to teach myself persisting objects into PostgreSQL using Glorp and a GUI.

My suggestion to the SqueakDBX team is to incllude a working sample but this time based on the Morphic UI Designer.
  ----- Original Message ----- 
  From: Mariano Martinez Peck 
  To: Germán Arduino 
  Cc: ESUG Mailing list ; A friendly place where any question about pharo is welcome ; Pharo Development ; The general-purpose Squeak developers list 
  Sent: Friday, March 04, 2011 7:53 AM
  Subject: Re: [Esug-list] [squeak-dev] [ANN] ESUG supports once againSqueakDBX

  On Fri, Mar 4, 2011 at 11:50 AM, Germán Arduino <garduino at gmail.com> wrote:

    Certainly all the Smalltalk community should thank ESUG by the
    continous support to lot of initiatives.

  And to ESUG sponsors :)
  and ESUG conference attendees...and...and..lots of people :)
    Thanks ESUG.

    2011/3/4 Mariano Martinez Peck <marianopeck at gmail.com>:

    > We are really happy to announce that ESUG will sponsor us once again through
    > the ESUG Summer Talk project. This means that we have reached the ESUG
    > expectations and that they still think that relational database access is an
    > important matter in Smalltalk.
    > One important thing is that we are going to rename the project (we are still
    > working on it) since SqueakDBX runs not only in Squeak but also in Pharo,
    > and there have been even ports to Dolphin. What's the reason for this
    > decision? Because we do not want to couple ourselves to a smalltalk dialect
    > nor to OpenDBX, because our project is much more than that (later I will
    > tell you about our plans). So, these are some of the possible names:
    > ObjectPark, SmallParking, Parktalk, SmallValet, Valetalk, ValetST,
    > NorayTalk, Ballard, Noray and Cruise. Please let us know which one is your
    > favourite or help us find a new one.
    > Another important subject is the team. There will be three "mentors",
    > Esteban Lorenzano, Diogenes Moreira and myself, Mariano Martinez Peck; and
    > three students: Guillermo Polito, Nicolas Scarcella and Santiago Bragagnolo.
    > We are open to suggestions and ideas. In addition, we have defined a
    > possible list of actions that I copy at the end of the email.
    > For the moment, the url remains www.squeakdbx.org and the mailing
    > list squeakdbx at lists.squeakfoundation.org
    > Once again, we want to thank ESUG for their support and trust.
    > Thank you very much,
    > SqueakDBX team
    > Possible list of actions:
    > 1) Change SqueakDBX’s name.
    > 2) Update GLORP version since the actual one is 3 years old.
    > Port it again from VisualWorks, create a VW porting tool (may be).
    > Complete support to Glorp.  Today it works with PostgreSQL, Oracle and
    > MySQL.  Make it work with most databases OpenDBX supports.
    > 3) Create a lightweight solution, alternatively to GLORP.  There are some
    > options:
    > Make SqueakSave work with SqueakDBX.  SqueakSave developers already
    > contacted us because they wanted to do it. SqueakSave seems to be 20% slower
    > than Glorp but you don't need to write the mappings :)
    > Adapt Ramon Leon's active record to use an abstract database driver, and
    > create a driver for SqueakDBX.
    > Port the new Glorp’s kind of active record to Pharo. (included in 2).
    > 4) Write a Pharo By Example 2 chapter based on the card game Stef built ;).
    > 5) Cog compatibility.
    > 6) Use Alien instead of FFI.
    > Eliot is working on a threaded CogVM. One of the projects of the GSoC of
    > this year was to make something similar to a threaded FFI. What the student
    > did is a modification in Alien (I think) that can be run in a multithreaded
    > envirorment. He worked with Eliot. The idea is when Eliot releases the
    > threaded CogVM, this FFI would work our of the box, and would avoid locking
    > the WHOLE vm while a C function is being invoked (as it happens today with
    > FFI).....So....when that VM is released, we MUST migrate to that).
    > 7) Explore performance issues (maybe with our approach of "In thread
    > execution plugin").
    > 8) Complete integration with OpenDBX. For example, Oracle, for large objects
    > (Clob, Blob, etc) use specific functions. There are specific functions in
    > OpenDBX that have to be used if the database uses specific functions (oracle
    > is the only one for the moment.). We don't manage those functions yet.
    > 9) In this link http://www.squeakdbx.org/Targets%20and%20Features
    > You can see a list of future possible features like Connection pooling (now
    > it is done!), Prepared statement interface, Store procedures, Escape and
    > avoid of SQL insertion, Authentication support: extends to other methods,
    > not only user/password, Full text support, etc.


  Esug-list mailing list
  Esug-list at lists.esug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110304/22afc973/attachment.htm

More information about the Squeak-dev mailing list