Sabra Crolleton sabra.crolleton@gmail.com writes:
Hi Timo,
I can probably add the identity column stuff to daos this weekend and that would solve your first issue. I have to admit that I do not use daos (just sql or s-sql), so they have never been a high priority for me.
With respect to references and foreign keys to other tables, I can also try to write up an explanation this weekend, but please understand that postmodern daos are really simple. They are not full ORMs. Maybe someone else on the mailing list can write up how they use them.
Yeah, my use cases seem bit cleaner with few daos and some more direct sql. Daos seem nice until you get to more complex queries and then they seem to add just confusion. At least thats been my experience from moving to manually mapping raw sql query results to objects vs. heavy use of ORM library. It would be great if identity gets added to daos. Would make things a bit more consistent.
From a design standpoint, I agree that I would not include user passwords in a dao class with the rest of the user information. (I do hope those are salted passwords as well.) That also implies that passwords should not be in the same table as the rest of the user information. However, your password validation function just needs the user id and the password to be tested. Why pass around an entire user dao? (This shows my biases as a dba rather than a developer.)
But I am confused by your comment about adding a method to a user dao class. Common lisp classes do not have methods. Methods are generic and are specialized on their parameters. So I could write a validate-password generic function that takes two parameters, a user-id and a password string. Then I would write two methods, one that accepted an integer as the user-id parameter and a second method that accepted a user-dao as the user-id parameter (and then internally extracted the user-id out of the user dao). See, e.g. the explanations here: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html
Sabra
By "adding method to class" I meant adding generic function method specializing to user dao. But as pointed out, probably seem a bit too 'complex' when regular function will work as well.
Well, perhaps the code structure starts to become clearer once my project progresses.
timo
On Tue, Jun 9, 2020 at 4:01 PM Timo Myyrä timo.myyra@bittivirhe.fi wrote:
Hi,
So the best bet would be to just use the create-table to create the database structure and then define dao classes separately. I was trying to avoid that as I'd guess it will be easy to have definitions given on create-table and dao class to drift apart. I was trying to avoid that by using just dao so database stuff would be given on just one place.
But now that we're talking daos, how should I handle references to other tables with dao class? If we take the User dao class for example, I add the users table and define the user dao. I have then separate passwords table that stores user passwords. It doesn't feel right to make passwords an dao class. The passwords are tied very tighly to user so it would seeem logical to query the passwords with user dao. What would be 'idiomatic way' to do this with postmodern? Just use the user dao class and add an method to it, which makes normal sql query for users passwords? Just define password dao and query it with user id?
A bit basic questions. The documents and examples show small cases so its hard to see the big picture from them.
timo
Sabra Crolleton sabra.crolleton@gmail.com writes:
Hello Timo,
A couple of notes here. First "user" is a restricted word for postgresql, so I suggest naming the table "users" instead.
Second, your s-sql sample create table misplaced a paren. You need
another
paren after the username column and before the primary key
I agree that daos do not yet have identity columns, but that really only prevents you from creating a table using the dao.
So consider the following where we create a table using s-sql, insert
some
items, demonstrate that we can retrieve an item using a dao, then demonstrate we can create a dao item, insert it in the table and then retrieve it.
Postgresql
handles all the identity stuff. Also note that I used "users" as the table, but I can create a dao class named "user".
(query (:create-table (:if-not-exists 'users) ((id :type integer :identity-always t) (username :type text)) (:primary-key id)))
(query (:insert-rows-into 'users :columns 'username :values '(("Jason") ("Tim") ("Karolyn"))))
(defclass user () ((id :col-type integer :accessor id) (username :col-type text :initarg :username :accessor username)) (:metaclass dao-class) (:table-name users) (:keys id))
(username (get-dao 'user 1)) "Jason"
(let ((item (make-instance 'user :username "Zenya"))) (insert-dao item))
(username (get-dao 'user 4))
"Zenya"
Does this help?
Sabra Crolleton
On Tue, Jun 9, 2020 at 12:41 PM Timo Myyrä timo.myyra@bittivirhe.fi
wrote:
Hi,
I'm learning to use postmodern as part of my hobby project but I've hit
a
small bump in the process. I can have the identity column defined for table without dao with something like: (s-sql:sql (:create-table (:if-not-exists 'user) ((id :type int :identity-always t) (username :type text) (:primary-key id)))
But I intent to use dao classes so it would be nice to have identity column specified as part to defclass slot options. Is there some way to create dao class with identity column?
Br, Timo M