April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] relational database and id field

by Alexandre Bergel

Thanks you all guys! You rock! Alexandre On 7 Apr 2011, at 08:25, Schwab,Wilhelm K wrote: > Expert? Certainly not me :) The question I will be waiting to see debated is whether you should "fabricate" an ID field (probably a counter), use ISBN or similar number, or use a compound key. FWIW, I invariably regret any decision I make in these areas, because there are tradeoffs. Relational databases are very good at what they do, which is storing tabular data and (most importantly) getting it back later; they are also a pain about it :( > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre.bergel(a)me.com] > Sent: Thursday, April 07, 2011 9:19 AM > To: Pharo Development > Subject: [Pharo-project] relational database and id field > > Hi! > > Since there are some experts in databases here, I ask a general question about it. > Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] relational database and id field

by Alexandre Bergel

> Normally, you should always have a primary key to uniquely identify a record in a database table. If you have an attribute (or a set of attributes) that can uniquely identify your ComicBook, you don't need an id field. BUT, if you tell me you're going to store lots and lots and lots of those ComicBook instances, having an id (integer) as the primary key has potential non-negligeable advantages over, say, something like a name. Mainly because an id (let's suppose it's an INT) takes way less storage than say a name (VARCHAR(30) for instance) and thus more index records can fit into the key buffer in memory. Ok, I understand. > 1) yes, always provide a primary key > 2) if you have already A primary key (even a composite one) > 2a) if you need performance and are gonna store LOTS of those objects, the smaller the key the better so you could create a surrogate key (the id key) instead of using the "real" primary key > 2b) if performance is not an issue, you can use what is already available that uniquely identifies your object (row) in the database table Thanks! > P.S. Are you using a particular OO-RDBMS framework? No, I am correcting a student thesis :-) I would probably not use SQL if I had to :-) Cheers, Alexandre > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > From: Alexandre Bergel <alexandre.bergel(a)me.com> > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thu, April 7, 2011 9:19:03 AM > Subject: [Pharo-project] relational database and id field > > Hi! > > Since there are some experts in databases here, I ask a general question about it. > Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] relational database and id field

by Schwab,Wilhelm K

That sounds like a one-to-many relationship. In those cases, I create two tables, one for the singleton side and one for the many side. The many side includes the key field(s) from the one side, and setting it/them establishes the relationship. A unique ID field for the singleton side is helpful, especially if things get edited. For many to many, I create a third table that does nothing but associate keys between the two tables - I'm not even sure if there is another way to do it?? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Benoit St-Jean [bstjean(a)yahoo.com] Sent: Thursday, April 07, 2011 8:57 AM To: Alexandre Bergel Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] relational database and id field One more remark, Since you're storing objects into a RDBMS, I guess what you're trying to express into "the relational world" is a notion of pointer (such as an object contains a collection of something in one of its instance variable, or a child has a mother kinda relationship, link). In that case, to save you headaches and lots of "weird object-oriented modeling", an oid (object id) is what is used normally. Any sequence (the shorter the better, don't use GUID for instance!) would do... ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Alexandre Bergel <alexandre.bergel(a)me.com> To: Benoit St-Jean <bstjean(a)yahoo.com> Cc: Pharo-project(a)lists.gforge.inria.fr Sent: Thu, April 7, 2011 9:49:11 AM Subject: Re: [Pharo-project] relational database and id field > Normally, you should always have a primary key to uniquely identify a record in a database table. If you have an attribute (or a set of attributes) that can uniquely identify your ComicBook, you don't need an id field. BUT, if you tell me you're going to store lots and lots and lots of those ComicBook instances, having an id (integer) as the primary key has potential non-negligeable advantages over, say, something like a name. Mainly because an id (let's suppose it's an INT) takes way less storage than say a name (VARCHAR(30) for instance) and thus more index records can fit into the key buffer in memory. Ok, I understand. > 1) yes, always provide a primary key > 2) if you have already A primary key (even a composite one) > 2a) if you need performance and are gonna store LOTS of those objects, the smaller the key the better so you could create a surrogate key (the id key) instead of using the "real" primary key > 2b) if performance is not an issue, you can use what is already available that uniquely identifies your object (row) in the database table Thanks! > P.S. Are you using a particular OO-RDBMS framework? No, I am correcting a student thesis :-) I would probably not use SQL if I had to :-) Cheers, Alexandre > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > From: Alexandre Bergel <alexandre.bergel(a)me.com<mailto:alexandre.bergel@me.com>> > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr>> > Sent: Thu, April 7, 2011 9:19:03 AM > Subject: [Pharo-project] relational database and id field > > Hi! > > Since there are some experts in databases here, I ask a general question about it. > Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] relational database and id field

by Alexandre Bergel

> Expert? Certainly not me :) The question I will be waiting to see debated is whether you should "fabricate" an ID field (probably a counter), use ISBN or similar number, or use a compound key. FWIW, I invariably regret any decision I make in these areas, because there are tradeoffs. Relational databases are very good at what they do, which is storing tabular data and (most importantly) getting it back later; they are also a pain about it :( Thanks Bill. I share your opinion. Alexandre > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Alexandre Bergel [alexandre.bergel(a)me.com] > Sent: Thursday, April 07, 2011 9:19 AM > To: Pharo Development > Subject: [Pharo-project] relational database and id field > > Hi! > > Since there are some experts in databases here, I ask a general question about it. > Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. > Should the class ComicBook have a field id to uniquely identify a book? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

[Pharo-project] An idea about Pluggable widgets

by Igor Stasenko

I have an idea how to refactor the pluggable morphs mess. The main principle behind all pluggables, that you have a model (which is held in instance variable), and then morph having additional ivars to speak with this model, which the selector names you should use to access certain state from model. For example: AlignmentMorph subclass: #PluggableButtonMorph instanceVariableNames: 'model label getStateSelector actionSelector getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging triggerOnMouseDown offColor onColor feedbackColor showSelectionFeedback allButtons arguments argumentsProvider argumentsSelector gradientLook enabled actionBlock getColorSelector getEnabledSelector' classVariableNames: 'UseGradientLook' poolDictionaries: '' category: 'Morphic-Pluggable Widgets' as you can see it is crowded with all those ivars, where part of them used to speak with model, and part of them used for keeping flags and additional parameters which you can customize when creating a button. getStateSelector actionSelector getLabelSelector getMenuSelector arguments argumentsProvider argumentsSelector gradientLook actionBlock getColorSelector getEnabledSelector and this is really messy.. Take a look at code: performAction "Inform the model that this button has been pressed. Sent by the controller when this button is pressed. If the button's actionSelector takes any arguments, they are obtained dynamically by sending the argumentSelector to the argumentsProvider" enabled ifFalse: [^self]. askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]]. self actionBlock ifNotNil: [ ^ self actionBlock value]. actionSelector ifNotNil: [actionSelector numArgs == 0 ifTrue: [model perform: actionSelector] ifFalse: [argumentsProvider ifNotNil: [arguments := argumentsProvider perform: argumentsSelector]. model perform: actionSelector withArguments: arguments]] Now think if we could replace this with simple: performAction "Inform the model that this button has been pressed. Sent by the controller when this button is pressed. If the button's actionSelector takes any arguments, they are obtained dynamically by sending the argumentSelector to the argumentsProvider" enabled ifFalse: [^self]. model performAction. so, in this case, we just put an obligation onto model to perform any action in response to button clicked, and button no longer cares about crappy logic how it should send a message to model (via action block, via actionSelector ... and whether it should pass any additional arguments or not..) So, in all places which using things in a way like: getListItems ^ model perform: getListItemsSelector now will be replaced with clean: getListItems ^ model getListItems So, a pluggable morph no longer cares about keeping all those selectors and maintain an obscure logic whether selector is nil or not nil etc etc.. Let model handle it! Then you may ask, what if i have a model, which doesn't implements such protocol (required for specific pluggable widget). The answer is simple: - create a pluggable model class for given widget, which wraps around your object and can keeps all those messy 'getLabelSelector' 'getMenuSelector' , inside and mediates between your model and widget. The benefit of it that widgets code will be much more cleaner. And another benefit is that you know what exact protocol is needed if you want to use your object as a model to given widget (list, button etc). And in most of the cases, you don't need to use this messy 'getXYZSelector', because you can simply answer to messages sent by widget and provide necessary data. But if you wanna go messy, you just use wrapper model, which contains all those 'getXYZSelectors' which you can set to whatever you like. -- Best regards, Igor Stasenko AKA sig.

April 7, 2011

[Pharo-project] relational database and id field

by Alexandre Bergel

Hi! Since there are some experts in databases here, I ask a general question about it. Assume that I have to use a relational database to store, let's stay instances of Stef's ComicBook class. Should the class ComicBook have a field id to uniquely identify a book? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 7, 2011

Re: [Pharo-project] Finder and finding by example

by Benjamin

No problem, you are not the first one that complain about that, so many I should make the Finder a bit more intelligent Thanks for your feedback, it's always important ;) Ben On Apr 7, 2011, at 3:10 PM, Friedrich Dominicus wrote: > Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > >> What do I have to do to make finder working >> as the method finder before. >> >> I wanted to type in the example code >> >> '123' . '12' > Found it just after sending to this mailing list > I've to change to examples and from there it works. > > Sorry for bothering you > Friedrich >

April 7, 2011

Re: [Pharo-project] Finder and finding by example

by Marcus Denker

On Apr 7, 2011, at 3:10 PM, Friedrich Dominicus wrote: > What do I have to do to make finder working > as the method finder before. > > I wanted to type in the example code > > '123' . '12' > > and that yields allButLast in MethodFinder > > I tried in the new Finder (Pharo 1.2) but it yields nothing. > > What am I missing? For me it works. I do select "Examples" instead of "Selectors" in the drop-down menu. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 7, 2011

Re: [Pharo-project] Finder and finding by example

by Friedrich Dominicus

Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > What do I have to do to make finder working > as the method finder before. > > I wanted to type in the example code > > '123' . '12' Found it just after sending to this mailing list I've to change to examples and from there it works. Sorry for bothering you Friedrich

April 7, 2011

[Pharo-project] Finder and finding by example

by Friedrich Dominicus

What do I have to do to make finder working as the method finder before. I wanted to type in the example code '123' . '12' and that yields allButLast in MethodFinder I tried in the new Finder (Pharo 1.2) but it yields nothing. What am I missing? Regards Friedrich

April 7, 2011