[postmodern-devel] Exlcuding slots dao-save
Hi I am trying to figure out how to exclude certain slots when persisting the dao instance to the db short of making a new object with the limited range of slots. Any ideas or advise? Thanx
Hi Phil, I am not entirely sure what you mean. Do you want extra slots in the object that don't correspond to db columns? Then just don't give them any Postmodern-specific options, and they will be normal slots. Or you have two similar tables, one with a superset of columns of the other? In that case, make a class for the smaller table, and create one that inherits from that for the bigger table. Does that help? Best, Marijn On Sun, Oct 25, 2009 at 4:45 PM, Phil Marneweck <zaries@global.co.za> wrote:
Hi
I am trying to figure out how to exclude certain slots when persisting the dao instance to the db short of making a new object with the limited range of slots.
Any ideas or advise?
Thanx
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
I want slots that correspond to db columns but are not considered on insert and update. I want to use oid but dont want postmodern to try and update it because this gives an error. On Sun, 2009-10-25 at 17:17 +0100, Marijn Haverbeke wrote:
Hi Phil,
I am not entirely sure what you mean. Do you want extra slots in the object that don't correspond to db columns? Then just don't give them any Postmodern-specific options, and they will be normal slots. Or you have two similar tables, one with a superset of columns of the other? In that case, make a class for the smaller table, and create one that inherits from that for the bigger table. Does that help?
Best, Marijn
On Sun, Oct 25, 2009 at 4:45 PM, Phil Marneweck <zaries@global.co.za> wrote:
Hi
I am trying to figure out how to exclude certain slots when persisting the dao instance to the db short of making a new object with the limited range of slots.
Any ideas or advise?
Thanx
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Ah, that's a case I had not thought about before. I've never touched oid columns and similar magic things. So these have to be selected (and retrieved on insert), but not written to? It should be easy to add a new slot flag to do just that. Any chance you can do this yourself? (The relevant code is all in postmodern/table.lisp, but contains some weird MOP-related work-arounds.) Best, Marijn
I could most propibly figure something out, I have been staring at table.lisp the whole afternoon. I need this for the postmodern-store I am writing for weblocks so if I did make the changes I would like to do it in such a way that the code can find its way into the main stream. There are a few options: - Cater just for oid ie mark a slot as the oid. - Mark any slot as not updatable. - ??? Which one would be best? On Sun, 2009-10-25 at 17:36 +0100, Marijn Haverbeke wrote:
Ah, that's a case I had not thought about before. I've never touched oid columns and similar magic things. So these have to be selected (and retrieved on insert), but not written to? It should be easy to add a new slot flag to do just that. Any chance you can do this yourself? (The relevant code is all in postmodern/table.lisp, but contains some weird MOP-related work-arounds.)
Best, Marijn
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
There is the serial type as well and I don't know if there are GUID types I dont see any in the type list. And I think you can update a serial or specify a value on insert... I had a quick look at the code and I don't see that the record is reselected for insert under at any time so i gues serial is also not handles correctly. I think we migh thave to settle for :auto-generated and :read-only because we only want to fetch the value auto generated instances on insert to refresh the dao instance. ? On Sun, 2009-10-25 at 17:57 +0100, Marijn Haverbeke wrote:
- Cater just for oid ie mark a slot as the oid. - Mark any slot as not updatable. - ???
Does Postgres provide more columns like this? If not, the first sounds least confusing.
Or we could just call this 'read-only slots', which describes the functionality pretty well.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
I had a quick look at the code and I don't see that the record is reselected for insert under at any time so i gues serial is also not handles correctly.
That's the :returning clause on line 199.
I think we migh thave to settle for :auto-generated and :read-only because we only want to fetch the value auto generated instances on insert to refresh the dao instance.
See above. The idea is that after an insert, the instance properly reflects the row in the database.
I notice the returning just after sending the mail :( Well then its :read-only... will let you know when i got something working...hope fully in an hour or so On Sun, 2009-10-25 at 18:25 +0100, Marijn Haverbeke wrote:
I had a quick look at the code and I don't see that the record is reselected for insert under at any time so i gues serial is also not handles correctly.
That's the :returning clause on line 199.
I think we migh thave to settle for :auto-generated and :read-only because we only want to fetch the value auto generated instances on insert to refresh the dao instance.
See above. The idea is that after an insert, the instance properly reflects the row in the database.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Took a life time longer but it looks like i got it working without mangling the code to badly. I tested it with the postmodern-store I am writing looks like it works fine. On Sun, 2009-10-25 at 20:09 +0200, Phil Marneweck wrote:
I notice the returning just after sending the mail :(
Well then its :read-only... will let you know when i got something working...hope fully in an hour or so
On Sun, 2009-10-25 at 18:25 +0100, Marijn Haverbeke wrote:
I had a quick look at the code and I don't see that the record is reselected for insert under at any time so i gues serial is also not handles correctly.
That's the :returning clause on line 199.
I think we migh thave to settle for :auto-generated and :read-only because we only want to fetch the value auto generated instances on insert to refresh the dao instance.
See above. The idea is that after an insert, the instance properly reflects the row in the database.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
I have test cases but I need to clean them up and I want to just have one last look (most of it as done late last night and code looks different in the morening ;)) before I mail it to you. One issue I have is that if you make a new instance of a dao and the record alread exist in the db and you run save on this the record the update is done correctly. It does not however populate the oid in an update only in an insert. I am not sure whether this is postmodern's problem or the users. For me it is in a sense the user/programmer problem. However letting postmodern protect itself against such would keep the is this a bug or feature mails on the mailing list down to a minumum. The only other time that I can think of that this could become an issue is if the user has triggers on the table that change data before it goes into the db. Then updating the object after a an update would be essential but then you cant just check for unbound slots you have to check all the fields. On Mon, 2009-10-26 at 07:44 +0100, Marijn Haverbeke wrote:
Took a life time longer but it looks like i got it working without mangling the code to badly.
Great! I'd be happy to review it and merge it into my repo. If you have a test case that demonstrates how you're using this, that would also help.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Phil, Sending code to the list is okay. I have incorporated your changes, with the difference that I'm now calling the option :ghost, since :read-only might actually lead people to expect something completely different. Let me know if the changes work for you. Best, Marijn
Hi I will give it a try just now. This feauture might come in handier than expected. It can be used to build objects over "views". This way you can also persist the "main" table in the view from the dao. The "view objects" is going to be an issue for me in the weblocks store. I see that clsql has joins in there objects. How to work with views and dao combination is not clear in my mind yet. Maybe we should look at complete ghost daos? Any ideas? On Tue, 2009-10-27 at 10:30 +0100, Marijn Haverbeke wrote:
Phil,
Sending code to the list is okay.
I have incorporated your changes, with the difference that I'm now calling the option :ghost, since :read-only might actually lead people to expect something completely different. Let me know if the changes work for you.
Best, Marijn
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Can you be more specific about the problems that come up with views? In the past, I've just used regular DAO classes on views, and never updated or inserted them.
It is the combination of weblocks and "views" (with views i mean just a query with joins, groupings etc) that is the problem. I suspect that weblocks thinks any object has a one to one relation to a table and thus treats it like that. However I could be wrong I still need to do some more testing to see what weblocks' behaviour/expectations are exactly. Once I have done that I will come back to you with more specifics. On Tue, 2009-10-27 at 10:58 +0100, Marijn Haverbeke wrote:
Can you be more specific about the problems that come up with views? In the past, I've just used regular DAO classes on views, and never updated or inserted them.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
On Sun, 2009-10-25 at 17:17 +0100, Marijn Haverbeke wrote: ..... Do you want extra slots in the object that don't correspond to db columns? Then just don't give them any Postmodern-specific options, and they will be normal slots.
This does not seem to be true for me. But then again I could be defining the class wrong (my knowledge of clos is very limited). Using update-dao I get : SIMPLE-ERROR: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION POSTMODERN:UPDATE-DAO (3)> when called with arguments (#<EMPLOYEE {1003E00FB1}>). The class: (defclass employee () ((id :accessor employee-id :col-type integer) (first-name :initarg :first-name :accessor first-name :col-type string) (last-name :initarg :last-name :accessor last-name :col-type string) (age :initarg :age :accessor age :col-type integer) (address-id :initarg :address-id :accessor employee-address-id :col-type integer ) (company-id :initarg :company-id :accessor employee-company-id :col-type integer ) (address :accessor employee-address :initform (make-instance 'address) :type address ) (company :accessor employee-company :type company ) )
Sorry it is there I just missed it in the cut and paste... On Fri, 2009-11-06 at 17:55 +0100, Marijn Haverbeke wrote:
Your class definition does not contain a :metaclass clause.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Ah..that was the problem...sorry to be posting with such simple mistake..I just had to many versions of the class as I tried different things today...the key got lost on the way...*blush* On Fri, 2009-11-06 at 18:56 +0100, Marijn Haverbeke wrote:
On Fri, Nov 6, 2009 at 6:28 PM, Phil Marneweck <zaries@global.co.za> wrote:
Sorry it is there I just missed it in the cut and paste...
Ah. Did you also leave out the :keys declaration? You need a primary key to be able to update.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Hi I have completed the postmodern store I was working on and I am including the code in this mail. There are two "modes" that you can use the store in. The default is by supplying your own unique ids for all tables in the db so that weblocks can work. The second mode uses oid's to supply weblocks with unique ids. To facilitate the use of oid's you will need the latest postmodern code that has the :ghost functionality (clbuild retrieves this version). Things to look at: 1. I create a new class based on dao-class called dao-store-class. I do this to add the direct slot for foreign keys. Currently you need to pass lists to this slot. If mop was used to create a slot-class for this it could replace the lists. I am however far from comfortable with mop (even after staring at the code in postmodern's table.lisp or maybe it was because I looked at that as an example that I did not feel up to the task). The other matter is that the handling of foreign keys might be nice to add into postmodern itself. 2. I used strings to build some of the select statments. This is because I could not get the syntax right to have a compile-sql use s-sql to build these selects. See comments in code. 3. The unit tests I have written to test the store without weblocks are really crappy and need to be redone to be lispy and to handle more scenarios. Some of the tests dont clean up after themselves properly when they fail so test can't be re-run without cleaning the db. The unit tests also only test the OID version of the store. I have tested the store (in default mode) with the weblocks store demo code that I adjusted to work with the postmodern store and all scenarios there work fine. Any and all comments/code would be welcome. I am relatively new to lisp and will remain relatively new for some time still to come. There is a lot to learn and a lot I still need to practice. Regards
Great! Does it have a project page yet? You should put it on github.
I did not really want to create a separate project for it. I was just hoping for some feedback here on this list before I hand it of to the weblocks guys. If they are happy enough with it they can work it into their repositories. From there anybody that is interested can then hack away. I just wanted to make sure that I did not "miss use" postmodern in my attempt to comply to what I interpreted to be the requirements of a weblocks store. I spent a good amount of time digging in the postmodern code to better understand how to use postmodern in the store. The main difference between the store and my day to day use of posmodern is that the store hangs onto the connection object to re-use it. In a sense I already deviated a bit from this by disconnecting from the db after using it in the store (anticipating that the store would mostly be used by weblocks widgets that have a specific use scenario, giving me the chance to reconnect in the back ground). The store should be using postmodern's connection pooling to make reconnecting more efficient. There should also be some tracking of "explicit transactions" so as to not disconnect from the db when a transaction is active on a store. In the mean time I am using it for a project that has to be finished by Monday so it will see a lot of use in the next 30 hours. This will hopefully sort out any glaring bugs. What is left is bad lisp style and other stupid mistakes...;) On Sat, 2009-11-07 at 18:54 +0100, Marijn Haverbeke wrote:
Great! Does it have a project page yet? You should put it on github.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Found my first booboo I added some doucmentation notes before I mailed the code and messed up the class definition for dao-store-class...it should be as follows... (defclass dao-store-class (dao-class) ((foreign-keys :initarg :foreign-keys :initform nil :reader foreign-keys)) (:documentation "Expected Values are for foreign-keys is a list of foreign-key-id-slot-name foreign-key-boject-slot-name foreign-object-id-slot-name include-in-delete-p.")) Sorry every one. On Sat, 2009-11-07 at 20:36 +0200, Phil Marneweck wrote:
I did not really want to create a separate project for it. I was just hoping for some feedback here on this list before I hand it of to the weblocks guys. If they are happy enough with it they can work it into their repositories. From there anybody that is interested can then hack away.
I just wanted to make sure that I did not "miss use" postmodern in my attempt to comply to what I interpreted to be the requirements of a weblocks store.
I spent a good amount of time digging in the postmodern code to better understand how to use postmodern in the store.
The main difference between the store and my day to day use of posmodern is that the store hangs onto the connection object to re-use it. In a sense I already deviated a bit from this by disconnecting from the db after using it in the store (anticipating that the store would mostly be used by weblocks widgets that have a specific use scenario, giving me the chance to reconnect in the back ground).
The store should be using postmodern's connection pooling to make reconnecting more efficient.
There should also be some tracking of "explicit transactions" so as to not disconnect from the db when a transaction is active on a store.
In the mean time I am using it for a project that has to be finished by Monday so it will see a lot of use in the next 30 hours. This will hopefully sort out any glaring bugs.
What is left is bad lisp style and other stupid mistakes...;)
On Sat, 2009-11-07 at 18:54 +0100, Marijn Haverbeke wrote:
Great! Does it have a project page yet? You should put it on github.
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
_______________________________________________ postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
Just an update on the weblocks-postmodern store. It now has a home at http://bitbucket.org/harag/weblocks-dev/wiki/Home. This is a fork of the weblocks-dev repository while it is still under heavy development. If you clone this repository you will have what you need to run weblocks(not its dependencies) and the postmodern store. There is a demo of the postmodern store under the examples directory.
Some additional info: address and company are dao classes as well The idea is eventually(by tommorrow some time) to be able to update the child classes as well in the weblocks postmodern store I am working on. But for now I am just trying to get the main class to update. I dont know if some thing like updating the child classes from the main class could have value for postmodern itself. Any comments or suggestions would be most welcome. On Fri, 2009-11-06 at 18:33 +0200, Phil Marneweck wrote:
On Sun, 2009-10-25 at 17:17 +0100, Marijn Haverbeke wrote: ..... Do you want extra slots in the object that don't correspond to db columns? Then just don't give them any Postmodern-specific options, and they will be normal slots.
This does not seem to be true for me. But then again I could be defining the class wrong (my knowledge of clos is very limited).
Using update-dao I get :
SIMPLE-ERROR: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION POSTMODERN:UPDATE-DAO (3)> when called with arguments (#<EMPLOYEE {1003E00FB1}>).
The class:
(defclass employee () ((id :accessor employee-id :col-type integer) (first-name :initarg :first-name :accessor first-name :col-type string) (last-name :initarg :last-name :accessor last-name :col-type string) (age :initarg :age :accessor age :col-type integer) (address-id :initarg :address-id :accessor employee-address-id :col-type integer ) (company-id :initarg :company-id :accessor employee-company-id :col-type integer ) (address :accessor employee-address :initform (make-instance 'address) :type address ) (company :accessor employee-company :type company ) )
participants (2)
-
Marijn Haverbeke -
Phil Marneweck