-
-
Notifications
You must be signed in to change notification settings - Fork 428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: example of multiple sessions #471
base: main
Are you sure you want to change the base?
Conversation
hey is there any way to use our own db something like mongodb for sessions ? |
As far as I know, it only supports PostgreSQL, I don't see any point in using a non-relational database in this project. |
can we use slice or in-memory golang instead ? and implement an interface for it ? |
I believe it is possible, @tulir can help you better with this issue, as I have never implemented anything like this with Whatsmeow. |
yes i haseen the code on when do pair success it will call container.Save() and the function Save() is only implement the sqlstore method, i think we can implement another interface on memory slice type. |
Do you know that you can use PostgreSQL and SQLite in memory? |
Simply pass `:memory:` in the sqlite driver filename
…On Mon, 8 Apr, 2024, 1:27 am Mateus Fernandes de Mello, < ***@***.***> wrote:
can we use slice or in-memory golang instead ? and implement an interface
for it ?
I believe it is possible, @tulir <https://github.com/tulir> can help you
better with this issue, as I have never implemented anything like this with
Whatsmeow.
yes i haseen the code on when do pair success it will call
container.Save() and the function Save() is only implement the sqlstore
method, i think we can implement another interface on memory slice type.
Do you know that you can use PostgreSQL and SQLite in memory?
If your intention is to have the persistence layer in memory you can use
one of the two in memory, I believe it is the fastest and simplest way to
achieve this goal.
—
Reply to this email directly, view it on GitHub
<#471 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMHFAGOIXOGOVYYFWYKISDDY4GQL7AVCNFSM6AAAAAA5O3MX5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGU4DIMZVG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hello @mateusfmello, thank you. I've applied your method and managed to run a variable number of devices using a single binary. Is there a method to determine which device an event is originating from? |
From what I remember, within the messages comes the JID (WhatsApp ID) of the device, if you don't have it when making the connection and informing the handlers, pass the JID as a parameter to the handler methods that need to know which device the event came from / message. But I believe that the messages / events have the JID of the recipient / device, I'm just not sure at the moment. |
I have read more and found this on client.go:
I modified the wrapper a little for my needs and solved my multi sessions problem with it. |
Cool, i will try too
Pada Rab, 8 Mei 2024 15.36, lairhas ***@***.***> menulis:
… Hello @mateusfmello <https://github.com/mateusfmello>, thank you. I've
applied your method and managed to run a variable number of devices using a
single binary.
Is there a method to determine which device an event is originating from?
From what I remember, within the messages comes the JID (WhatsApp ID) of
the device, if you don't have it when making the connection and informing
the handlers, pass the JID as a parameter to the handler methods that need
to know which device the event came from / message.
But I believe that the messages / events have the JID of the recipient /
device, I'm just not sure at the moment.
I have read more and found this on client.go:
// If you want to access the Client instance inside the event handler, the recommended way is to
// wrap the whole handler in another struct:
type MyClient struct {
WAClient *whatsmeow.Client
eventHandlerID uint32
}
func (mycli *MyClient) register() {
mycli.eventHandlerID = mycli.WAClient.AddEventHandler(mycli.myEventHandler)
}
func (mycli *MyClient) myEventHandler(evt interface{}) {
// Handle event and access mycli.WAClient
}
I modified the wrapper a little for my needs and solved my multi sessions
problem with it.
—
Reply to this email directly, view it on GitHub
<#471 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALJQY2EIU5JUGUV67YW46GLZBHP2HAVCNFSM6AAAAAA5O3MX5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBQGA2TIOBYGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change complicates the structure of this file, and introduces concepts like this "fake database" that are not realistic onto how a person would usually configure whatsmeow..
This PR will serve to obscure how whatsmeow actually works, the main way people interact with whatsmeow now is via the client_test and main example due to the deletion of mdtest.
The only thing people need to know to actually make multiple clients is the methods of the Container (https://godocs.io/go.mau.fi/whatsmeow/store/sqlstore#Container).
We already have the note regarding that:
Line 39 in 69ba055
// If you want multiple sessions, remember their JIDs and use .GetDevice(jid) or .GetAllDevices() instead. |
Might as well add a basic Go programming "hello world" tutorial in this file at this point...
Honestly, I don't see any complexity in reading the changes, but this was the way I found to exemplify the use of multiple sessions and a single session, but if you have a better way in mind, it will be very useful for the project. "selectJIDFromFakeDatabase" was the way I used to exemplify the use of an identifier to retrieve the JID and proceed to connect the client, it wouldn't need to be a database, and the parameter wouldn't need to be the JID itself, it could be a username, email, UUID, any value that the developer uses to identify their users. But we can really improve this part of retrieving the JID and add notes to make it clear that this part is specific to each project and not to WhatsMeow. Although there is sqlstore#Container and a note about new developers on the project not being able to understand how to use multiple sessions, generating doubts. There are people who need a coded example to understand and from my point of view it is more understandable this way. What do you suggest for improvements? |
we could make this more intuitive in the library code itself, maybe like a listAllSessions thing and picking the first element of that instead of the whole "GetFirstDevice" thing |
In order to facilitate the initiation of new WhatsMeow users, I am adding another example that demonstrates the use of the project with multiple sessions.